cobolt_semantic::flagging::flag_high_subset informa de cada elemento por encima del high subset de COBOL-85: COMPUTE, EVALUATE, INITIALIZE, STRING, UNSTRING, SEARCH, CORRESPONDING, DIVIDE … REMAINDER, DISPLAY … UPON, ACCEPT … FROM DAY-OF-WEEK, INSPECT … CONVERTING, SET … TO TRUE, PERFORM … VARYING y … WITH TEST AFTER, IF … ELSE, la modificación de referencia, los nombres de datos cualificados, un cuarto subíndice, aritmética en una relación, condiciones de signo y complejas, ALTER … TO PROCEED TO, entradas de nivel 66 y 88, RENAMES … THROUGH, VALUE ALL, ASCENDING/DESCENDING KEY, una tabla de longitud variable con INDEXED BY, un REDEFINES de un REDEFINES, un ALPHABET con rango de literales, SYMBOLIC CHARACTERS, END PROGRAM, y la continuación de una palabra o de un literal numérico.
Todo lo de esa lista es COBOL-85 válido que RustCOBOL implementa y ejecuta. El análisis dice solamente "esto no compilaría en una implementación limitada al high subset", y por eso es un punto de entrada opcional que ninguna compilación ordinaria llama — la misma disciplina que la pasada de elementos obsoletos añadida en 1.62.30, y las dos son deliberadamente independientes: DATE-COMPILED es a la vez obsoleto y superior al subset, y NC303M y NC401M quieren cada uno verlo informado bajo su propia clase.
Dos de los elementos son léxicos y no sintácticos. Una línea de continuación existe en la imagen de tarjeta y ha desaparecido cuando llega al flujo de tokens — MUL + -TIPLY es simplemente la palabra MULTIPLY — así que el análisis lee el fuente junto a los tokens.
• Dos trampas que merecen quedar registradas
Un emparejador voraz esconde un detector erróneo. NC401M puntuó 40 de 40 a la primera, y uno de los cuarenta estaba mal. El detector de subíndices contaba comas, y una coma seguida de espacio es un separador que el lexer descarta — así que (A, B, C, D, 1) llega como cinco operandos sueltos y el detector nunca disparaba. Un flag espurio distinto ocupó su lugar, y como las expectativas reclaman el primer flag no reclamado anterior a ellas, los totales seguían cuadrando. Los subíndices se cuentan ahora como operandos menos operadores binarios, y la pasada flag imprime ambas listas completas cuando discrepan, ya que un excedente temprano siempre aflora como una queja sobre una línea perfectamente correcta al final.
No toda continuación está por encima del subset. Continuar un literal alfanumérico está disponible en todos los niveles de conformidad, y NC401M no marca su propio "SUPERCALIFRAGILISTICEXPIALIDO / -"CIOUS". Lo que marca es la continuación de una palabra o de un literal numérico. Ambos casos se distinguen por aquello con lo que arranca la continuación: una comilla reabre un literal, cualquier otra cosa continúa una palabra o un número.
• Dónde queda ahora NC
Todos los programas del módulo compilan, y 78 de 95 corren hasta el final informando cero fallos. Un programa no termina — NC201A se atasca en PFM-TEST-F4-13 — y dieciséis informan fallos. Los cinco miembros registrados como inalcanzables sin trabajo de arnés están todos puntuados, y los cinco pasan.
=== PowerRustCOBOL 1.62.34 — 2026-08-28 ===
NIST CCVS85 Nucleus (NC): un MOVE de grupo ya no cambia ningún byte. La ejecución se mantiene en 78 de 95 y la compilación en 95 de 95; las aserciones pasan de 117 -> 116 fallando, y NC252A de 10 -> 9. Ningún otro módulo fue tocado (GOLDEN RULE #9).
• Corregido — la categoría de un ítem numérico salía de su slot, no de su declaración
1.62.32 registró los movimientos de grupo exactos al byte como una limitación: almacenar los caracteres de una porción que sí deletrea un número costó tres programas limpios, así que un hijo numérico seguía re-renderizándose a través de su PICTURE y " 123" volvía como 00123. Esa medición era real, pero la causa no era la exactitud al byte — eran dos sitios que tomaban "¿qué hay en el slot?" como sustituto de "¿qué es este ítem?". El sustituto se sostenía solo mientras un ítem numérico no pudiera contener caracteres, y un MOVE de grupo es un movimiento alfanumérico que hace exactamente eso posible.
- CobolEnvironment::set asignaba sobre la imagen de bytes en vez de restaurar la identidad numérica del ítem. truncate_to_capacity lee el slot como CobolValue::Numeric para aplicar la regla de magnitud sin signo y el corte de orden alto, así que abandonaba en silencio — y SUBTRACT CORRESPONDING escribió -11 en un PIC 99 sin signo (NC253A SUB-TEST-F3-1, NC220M). Una escritura numérica sobre un slot que contiene bytes reconstruye ahora el ítem con su escala declarada y después asigna, de modo que MOVE 12 TO <PIC 9(3)V99> sigue aterrizando como 12.00.
- is_alphanumeric_field respondía desde el slot. Tras MOVE ZERO TO D-NAMES, la sentencia MOVE 7 TO DNAME-2 escribía por tanto los caracteres "7 ", justificados a la izquierda, en un ítem numérico (NC112A MOVE-TEST-F1-1-2 … -10). Un ítem declarado numérico nunca es ahora alfanumérico, contenga lo que contenga su slot.
Con esos dos arreglados, la exactitud al byte no cuesta nada: los mismos 78 programas limpios, una aserción mejor, y NC252A mejora. MOVE SRC TO DST a través de un grupo deja ahora cada byte donde estaba, que es lo que el estándar dice que hace.
• Verificación — cada detector de marcado queda fijado
flag_high_subset tiene ~30 detectores y 1.62.33 probó unitariamente 15 de ellos; el resto descansaba en el agregado de NC401M, que esa misma versión demostró que puede mentir (un detector muerto y un flag espurio se cancelaron y el total siguió leyendo 40 de 40). Los nueve restantes se prueban ahora individualmente — EVALUATE, SEARCH, IF … ELSE, GO TO., ALPHABET con rango de literales, SYMBOLIC CHARACTERS, una tabla de longitud variable con INDEXED BY, ASCENDING/DESCENDING KEY y END PROGRAM — cada uno junto a la grafía dentro del subset ante la que debe permanecer callado. Un INDEXED BY de longitud fija y un ALPHABET IS NATIVE no producen flag alguno, como debe ser. Ningún detector descansa ya en el agregado.
=== PowerRustCOBOL 1.62.35 — 2026-08-28 ===
NIST CCVS85 Nucleus (NC): ACCEPT … FROM <mnemonic> lee al operador. NC204M pasa de 15 aserciones fallando -> 3, las aserciones del módulo de 116 -> 104 fallando (97.7 % de 4562). La ejecución se mantiene en 78 de 95 y la compilación en 95 de 95 — NC204M conserva tres fallos, todos ellos un único defecto de REDEFINES sin relación con esto. Ningún otro módulo fue tocado (GOLDEN RULE #9).
• Corregido — un mnemónico declarado se leía como variable de entorno
SPECIAL-NAMES asocia un dispositivo del implementador con un nombre a elección del programa, y el Formato 1 de ACCEPT puede entonces nombrarlo:
Código:
SPECIAL-NAMES.
XXXXX057 IS ACCEPT-INPUT-DEVICE.
...
ACCEPT ACCEPT-D1 FROM ACCEPT-INPUT-DEVICE.
La cláusula ordinaria <implementor-name> [IS] <mnemonic> se saltaba token a token — solo la forma de switch (… ON STATUS IS …) se reconocía — así que nada registraba que el nombre había sido declarado. parse_accept_source caía a su último caso, la extensión de PowerRustCOBOL que lee una variable de entorno con ese nombre, no encontraba ninguna definida y no almacenaba nada. Toda lectura a través de un mnemónico devolvía vacío.
- El parser registra ahora la cláusula (Parser::mnemonics), igual que ya registra los switches, las clases y el símbolo de moneda; vive en el parser porque la ENVIRONMENT DIVISION precede a la PROCEDURE DIVISION, así que el conjunto declarado se conoce para cuando un ACCEPT lo necesita.
- AcceptSource::Mnemonic(String) (nuevo, al final del enum — el AST se serializa con bincode por ordinal de variante) marca la lectura estándar; el intérprete lo trata exactamente como un ACCEPT simple: una línea del operador, distribuida por un receptor de grupo y rellenada con espacios hasta la anchura del ítem.
- La extensión queda intacta: un nombre que ninguna cláusula SPECIAL-NAMES declara sigue leyendo la variable de entorno. Qué lectura aplica lo decide la declaración, nunca la grafía del nombre.
• Arnés — el mazo de operador de NC204M
NC204M es el gemelo de NC109M: quince ACCEPT, cada uno comparado contra un ítem emparejado cuyo valor el programa fija justo encima de la lectura. El mazo se recupera por tanto del fuente, no se inventa, exactamente como se hizo con el de NC109M — hasta los espacios significativos iniciales y finales, el QUOTE y el valor DISPLAY-F de 200 caracteres. nist_conformance lo suministra por la stdin del proceso hijo.
Doce de las quince comparaciones de NC204M pasan con eso en marcha. Las tres restantes (ACC-TEST-F1-10, -14-1, -14-2) son un único defecto separado: un solapamiento REDEFINES no comparte los bytes del ítem redefinido, así que TAB-ACCEPT lee espacios donde deberían estar los puntos de ACCEPT-VALUE21, y un grupo FILLER REDEFINES lee vacío tras un ACCEPT exitoso. Es la misma familia que NC107A y NC252A y no se aborda aquí.
• Documentación
- docs/cobol85-supported-syntax-en.md — la entrada de ACCEPT indica ahora cuál de las dos lecturas aplica y por qué. El marcador NIST se actualiza (NC 95/95 compile, 78/95 execution) y la sección que afirmaba que cinco miembros "can never reach 0 failures" se sustituye: los cinco están puntuados, así que no hay techo estructural por debajo de 95 en el eje de ejecución. Esa afirmación estaba desfasada desde 1.62.30.
- docs/developers-guide-en.md — una nueva sección "Naming the console: mnemonic device names" bajo SPECIAL-NAMES, incluida la nota de que un mnemónico declarado y un nombre no declarado son fuentes distintas.
• Conocido — ACCEPT … FROM ENVIRONMENT "name" es inalcanzable
Encontrado durante las pruebas, no causado por este cambio ni reparado por él: ENVIRONMENT se lexea como palabra clave propia (la división abre con ella), así que parse_accept_source nunca la ve como identificador y su rama ENVIRONMENT "name" está muerta — la sentencia se lee como FROM DATE y el literal suelto descarrila la frase que la sigue. FROM ENVIRONMENT-VALUE es una fuente distinta y funciona. Ningún programa NC escribe la forma literal, así que se registra aquí en vez de arreglarse dentro de una pasada de módulo (GOLDEN RULE #9).
=== PowerRustCOBOL 1.62.36 — 2026-08-28 ===
NIST CCVS85 Nucleus (NC): dos maneras en que un solapamiento REDEFINES perdía los bytes de su objetivo. NC204M queda ahora limpio, así que la ejecución pasa de 78 -> 79 de 95 y las aserciones de 104 -> 101 fallando (97.8 % de 4561). La compilación se mantiene en 95 de 95. Ningún otro módulo fue tocado (GOLDEN RULE #9). Ambos defectos parecían idénticos desde fuera — la descripción redefinidora volvía leyendo espacios como quiera que se hubiera rellenado el ítem que redescribe — y no tenían nada en común por debajo.
• Corregido — las claves de almacenamiento del solapamiento perdían sus cualificadores externos
sync_redefines sembraba la copia inicial recorriendo la declaración redefinidora desde una ruta de ancestros vacía, así que cada clave que escribía carecía de los cualificadores externos. Eso es invisible mientras los nombres dentro del solapamiento son únicos — canon_key devuelve una hoja única tal cual, se le dé la ruta que se le dé — y erróneo en cuanto uno se duplica, que es exactamente cuando la clave cualificada lleva la información.
NC204M declara TAB-A bajo ACCEPT-D21 y bajo ACCEPT-D23, así que su ACCEPT-D21 REDEFINES ACCEPT-VALUE21 escribía en una clave que nada leía jamás: ACC-TEST-F1-10 calculaba " ABCD " donde estaba declarado "....ABCD....". El recorrido lleva ahora la ruta de ancestros, construida igual que la construye init_decl_h — un grupo sin nombre no aporta nada, cada grupo con nombre se aporta a sí mismo — de modo que los dos coinciden en la respuesta.
• Corregido — una descripción redefinidora sin nombre no tenía clave alguna
02 FILLER REDEFINES <item>. nombra bytes que su objetivo ya posee, sin nombre propio. redefine_pairs solo se registraba if is_named, así que no existía par de solapamiento y ninguna escritura al objetivo llegaba jamás a la descripción: ACC-14-CHARS-1-10 leía vacío tras un ACCEPT exitoso en el ítem que redescribe (ACC-TEST-F1-14-1, -14-2).
Una hoja sin nombre ya recibe una clave sintética bajo su padre; un grupo sin nombre que redefine recibe ahora lo mismo, registrado con el trazado de sus hijos con nombre, y la maquinaria ordinaria de solapamiento se hace cargo. Es una descripción, no un alias de su primer hijo: varios hijos se reparten los bytes del objetivo, y una escritura por cualquiera de los dos lados aterriza donde el trazado dice.
• Arnés — las dos últimas líneas del mazo de NC204M estaban mal
Hay que leer los solapamientos, no sus nombres: ambos grupos FILLER REDEFINES ACCEPT-TEST-14-DATA empiezan en el primer byte del ítem, así que ACC-14-CHARS-11-15 son los bytes 1–5 pese a lo que su nombre sugiere. Cada ACCEPT tiene por tanto que empezar con lo que comprueba el párrafo posterior, y el mazo es ahora "ABCDEFGHIJ" y luego "KLMNO" — que es también lo que las instrucciones de ejecución de CCVS85 hacen teclear al operador para el test VI-71 6.5.4 GR4(a).
• Conocido — un grupo sin nombre con hijos lee corto en su padre
Encontrado durante las pruebas, no causado por este cambio: 01 G. 02 T PIC X(5). 02 FILLER. 03 C1 PIC X(5). renderiza G como T a solas. Un grupo sin nombre con hijos aporta un slot FILLER sintético al trazado de su padre y luego no almacena nada en él, así que el padre lee corto. Aquí solo se repara la forma redefinidora; la forma simple queda registrada en vez de cambiarse dentro de una pasada de módulo (GOLDEN RULE #9), y a_plain_filler_group_is_not_treated_as_an_overlay fija la parte que es correcta.
=== PowerRustCOBOL 1.62.37 — 2026-08-28 ===
NIST CCVS85 Nucleus (NC): la protección de cheques rellena un CR/DB de dos caracteres. NC175A queda ahora limpio, así que la ejecución pasa de 79 -> 80 de 95 y las aserciones de 101 -> 98 fallando (97.9 % de 4560). La compilación se mantiene en 95 de 95. Ningún otro módulo fue tocado (GOLDEN RULE #9).
• Corregido — un cero protegido volvía un carácter más corto que su propia anchura
Un valor cero en una picture cuyas posiciones de dígito son todas * rellena cada posición de carácter con asteriscos, con la única excepción del punto decimal. El relleno recorría los símbolos expandidos de la picture y emitía un carácter por símbolo — pero CR y DB ocupan dos posiciones de carácter, que es exactamente lo que edited_width cuenta para ellos.
PIC $**.**CR conteniendo cero producía por tanto siete caracteres donde el ítem mide ocho, y lo que lo rellenaba hasta la anchura ponía un espacio en la última posición: "***.***" más un espacio, frente al "***.****" que el estándar exige (NC175A SUB-TEST-F2-28-5, -30-5, -32-5 — tres aserciones, una causa).
La ruta de valores distintos de cero ya era correcta y no cambia: allí solo se protegen los ceros iniciales, así que un $ solitario es una inserción fija que conserva su posición (-2.34 -> $*2.34CR), y CR se imprime porque el valor es negativo.
• Documentación
docs/cobol85-supported-syntax-en.md gana la regla de protección de cheques bajo PICTURE (y el marcador NIST pasa a 80/95); docs/developers-guide-en.md la gana junto al ejemplo PIC $**.**CR que ya llevaba, con la nota de que CR son dos posiciones de carácter.
=== PowerRustCOBOL 1.62.38 — 2026-08-28 ===
NIST CCVS85 Nucleus (NC): un literal numérico mueve sus caracteres, y un operando numérico comparado con uno no numérico se pseudo-mueve. NC202A y NC103A quedan ahora limpios y NC105A pasa de 18 -> 13, así que la ejecución alcanza 80 -> 82 de 95 y las aserciones 98 -> 88 fallando (98.1 % de 4559). La compilación se mantiene en 95 de 95. Ningún otro módulo fue tocado (GOLDEN RULE #9).
• Corregido — un literal numérico perdía los dígitos con los que fue escrito
COBOL-85 mueve los caracteres de un literal numérico a un receptor alfanumérico, no su valor. MOVE 060820000200 TO CORR-DATA-2, con seis hijos PIC 99, los rellena 06 08 20 00 02 00. El lexer conservaba solo el valor, así que el cero inicial desaparecía y los once dígitos restantes desplazaban cada hijo una posición a la izquierda; el ADD CORRESPONDING posterior calculaba 63 donde 09 era lo correcto (NC202A ADD-TEST-F3-7-1/2/3/5 — cuatro aserciones, una causa).
La anchura escrita viaja ahora como recuento de dígitos y no como texto, así que nada reserva memoria: Token::IntegerLiteral(i64, u8) y, para los literales que lo necesitan, Literal::IntegerDigits(i64, u8) (nuevo, al final del enum — el AST se serializa con bincode por ordinal). Un literal cuyo valor se renderiza de vuelta a lo escrito sigue siendo Literal::Integer, de modo que el caso ordinario conserva la forma que cada brazo existente ya maneja.
Ensanchar la aridad del token en vez de añadir una variante hermana es lo que hizo esto seguro: cada uno de sus 24 sitios de patrón se convirtió en error de compilación, así que el compilador enumeró el trabajo en vez de que un matches! dejara de casar en silencio. Atención: la anchura del receptor nunca interviene. MOVE 2 TO <PIC X(4)> sigue siendo "2 "; rellenar hasta el receptor lo convertiría en "0002".
• Corregido — comparar un operando numérico con uno no numérico
COBOL-85 VI-89 6.15.4 GR2: cuando un operando de una relación es numérico y el otro no numérico, la comparación es no numérica — el operando numérico se trata como si se hubiera movido a un ítem alfanumérico del mismo tamaño, lo que transfiere sus posiciones de carácter y no su signo operacional. Nosotros comparábamos algebraicamente, así que PIC S9(18) conteniendo -123456789012345678 no era igual a PIC X(18) conteniendo "123456789012345678" (NC103A IF-TEST-GF-98).
El pseudo-movimiento vive junto a as_comparand, donde un operando es todavía una expresión que nombra un ítem — "del mismo tamaño" es el tamaño del ítem, y un CobolValue ha dejado de ser un ítem para cuando compare_values lo ve.
Tres precondiciones deciden si la regla aplica, y cada una costó un programa mientras faltó: el operando numérico debe ser entero — el estándar lo dice, y un ítem PIC S9(9)V9(9) no tiene posición de carácter para su punto decimal, así que pseudo-moverlo hacía fallar comparaciones que imprimen igual (NC112A); "no numérico" es una propiedad de la declaración, nunca del slot — tras un MOVE de grupo un hijo PIC 99 contiene caracteres legítimamente, e IF XYZ-13 = 0 sigue siendo una relación entre dos operandos numéricos (NC208A MOV-TEST-F1-3); y ALL literal toma el tamaño del otro operando, porque no tiene otro — IF ALL "00" NOT > ZERO-D con ZERO-D PICTURE 9 compara contra un carácter (NC250A IF--TEST-106).
• Corregido — alphanumeric_capacity respondía desde el slot
El mismo sustituto que is_alphanumeric_field abandonó en 1.62.34, en su hermano y por la misma razón. Después de que un MOVE de grupo deje caracteres en un hijo PIC 9, MOVE ZERO TO DNAME-1 tomaba la ruta de relleno al estilo MOVE ALL y escribía "0" repetido hasta la anchura del slot de bytes, así que un ítem PICTURE 9 volvía leyendo 000 (NC112A MOVE-TEST-F1-2-*).
De todos modos comparaba igual a 0, porque la vieja comparación entre tipos forzaba ambos lados a número — un pase accidental sobre un ítem genuinamente erróneo, y uno que el arreglo de comparación de arriba convirtió en fallo honesto antes de que esto lo reparara. Un ítem declarado numérico nunca es alfanumérico, contenga lo que contenga su slot.
• Documentación
docs/cobol85-supported-syntax-en.md — las reglas de MOVE y de la condición de relación, y el marcador NIST en 82/95. docs/developers-guide-en.md — una sección "Comparing a number with text", ya que la regla es una con la que un desarrollador de PowerCOBOL o isCOBOL se topará la primera vez que compare un campo de pantalla contra un número.
• Conocido — el test de construcción de cobolt-ast no compila
Encontrado durante el barrido, preexistente y no tocado aquí: crates/cobolt-ast/tests/test_ast_construction.rs inicializa DataDecl sin justified ni sign, y Program sin cinco campos que esos tipos ganaron en sesiones anteriores. El target de tests del crate entero falla por tanto al construirse, así que no ha estado ejecutándose. Se informa en vez de repararse dentro de una pasada de módulo (GOLDEN RULE #9).
=== PowerRustCOBOL 1.62.39 — 2026-08-28 ===
NIST CCVS85 Nucleus (NC): un GO TO cualificado, y MOVE CORRESPONDING donde un lado de un par es un grupo. NC208A queda ahora limpio y NC209A pasa de 8 -> 7, así que la ejecución alcanza 82 -> 83 de 95 y las aserciones 88 -> 84 fallando (98.2 % de 4559). La compilación se mantiene en 95 de 95. Ningún otro módulo fue tocado (GOLDEN RULE #9).
• Corregido — GO TO paragraph {OF|IN} section ignoraba su cualificador
El cualificador escoge cuál de dos párrafos homónimos se quiere decir. PERFORM … OF … ya lo honraba; GO TO resolvía contra para_order, que está indexado por nombre pelado y devuelve la primera definición en cualquier parte del programa. NC208A declara PAR-4B en QUAL-SECTION-1 y en QUAL-SECTION-2 y salta a la segunda — aterrizaba en la primera, la copia cuyo propio comentario dice que jamás debe entrarse en ella (PAR-TEST-F2-4).
- Stmt::GoTo ganó section: Option<String> al final de sus campos (el AST se serializa con bincode por orden de declaración), parseado con el helper eat_procedure_name_qualified que PERFORM ya usa.
- RuntimeError::GoTo lleva el cualificador hasta el bucle que capture la señal, y un único resolutor — Interpreter::goto_index — es compartido por los sitios que antes llamaban a para_order.iter().position(…) directamente. Un cualificador desconocido cae a la búsqueda sin cualificar en vez de perder el salto, la misma elección que hace PERFORM … OF ….
- Dos casos deliberadamente no toman cualificador: GO TO … DEPENDING ON, cuyos objetivos son una lista pelada, y un GO TO que un ALTER ha redirigido — la redirección nombra su propio objetivo directamente. El despacho de programas anidados (run_para_sequence) ignora el cualificador a propósito: recorre el espacio de párrafos del propio programa, y section_span lee el externo.
• Corregido — un par corresponding con un grupo a un lado no movía nada
COBOL-85 pide solo que al menos un ítem de un par corresponding sea elemental, así que un grupo puede legítimamente encararse a un ítem elemental. Un grupo no posee slot de almacenamiento — su valor se sintetiza de sus ítems subordinados — de modo que: un receptor de grupo se escribía por env.set bajo el propio nombre del grupo, lo que dejaba el registro donde nada lo vuelve a leer (MOV-TEST-F1-4: fuente MOVE-CORR-4 PIC XXX = "XYZ", receptor un grupo de 999 + XXX, que conservó sus espacios); y un emisor de grupo se leía por env.get, que no producía nada, así que el receptor quedaba como estaba (MOV-TEST-F1-5: MOVE-CORR-G5 es un grupo de XXX + 99 enviando a un X(5) simple).
Ambos pasan ahora por las rutas conscientes de grupos — Interpreter::store_text y CobolEnvironment::group_value — que INSPECT (1.62.28) y ACCEPT (1.62.30) ya usan. Dos grupos encarados entre sí siguen recursando; ese emparejamiento no es el caso elemental y no se aplana en un único movimiento alfanumérico.
• Documentación
docs/cobol85-supported-syntax-en.md — el GO TO cualificado y la regla de CORRESPONDING con grupos, y el marcador NIST en 83/95. docs/developers-guide-en.md — ambos, junto al material al que pertenecen.
=== PowerRustCOBOL 1.62.40 — 2026-08-28 ===
NIST CCVS85 Nucleus (NC): constantes figurativas, fidelidad de bytes, JUSTIFIED, la prueba de clase NUMERIC, dos reglas de REDEFINES, un símbolo de moneda flotante y la serie de delimitadores de STRING. NC211A, NC174A, NC107A y NC217A quedan limpios, así que la ejecución pasa de 83 -> 87 de 95 y las aserciones fallidas bajan de 84 -> 53 (98,8 % de 4558). La compilación se mantiene en 95 de 95. Ningún otro módulo fue tocado (GOLDEN RULE #9).