Un ground truth humano para la equivalencia algorítmica

El objetivo, con su plantilla

Por qué hace falta

La pipeline declara isomorfas las 17 actividades, con distancia de edición cero: el 17-08-2026 con las reglas de entonces; el 19-09-2026 con reglas simplificadas y una ontología de 29 nodos curada a mano. Ese veredicto se contrasta con un juicio humano externo, porque las 17 actividades están refactorizadas para ser equivalentes y la pipeline está ajustada sobre esas mismas 17. El 18 y el 19-09-2026 el autor las alineó: mismos bloques, en el mismo orden y con los mismos operadores.

Los expertos leen programación por bloques y aplican las mismas reglas escritas que la pipeline, porque así la afirmación «son equivalentes» tiene un referente externo a la pipeline. Cada desacuerdo, entre expertos o entre expertos y máquina, se analiza regla por regla, porque señala una regla ambigua, ausente o discutible de la especificación. La pipeline se compara con jueces humanos sobre un corpus con negativos, porque un modelo de lenguaje decide su vocabulario canónico y construye sus grafos, y su fiabilidad se mide solo contra jueces humanos. Los negativos miden si la pipeline sabe decir «no».

El acuerdo entre expertos y pipeline mide si la pipeline implementa la especificación tal como la leen personas. La corrección de la especificación se mide con el juicio libre. Antes de recibir las reglas, cada experto da un juicio libre («¿dirías que son el mismo programa? ¿por qué?»), porque la distancia entre ese juicio y el juicio con reglas mide cuánto de la equivalencia crean las reglas.

La especificación que juzgan humanos y máquina

La equivalencia es relativa a una especificación. La especificación fija qué se observa, y el veredicto se sigue de ahí. La pipeline juzga «módulo plumbing de plataforma»: se descarta lo que una plataforma exige y la otra no. La especificación es una página: las reglas de normalización de prompt.md, escritas para personas, con un ejemplo por regla. Ese texto se entrega íntegro a los expertos y al LLM-juez. Es el primer entregable.

El 19-09-2026 se quitaron tres reglas que ya no hacen falta: «ejes x/y indiferentes», «Hz y nota = misma altura» y «sonido por intención» (tono ≠ sonido de evento ≠ clip grabado), que era la regla C. La regla C dice ahora solo que todos los sonidos son tonos (suenan 12 de las 17 actividades): «tono de timbre (Hz)» y «para todos los sonidos» en el micro:bit; «tocar nota» o «tocar frecuencia» y «detener» en Protobject. El tono suena hasta el siguiente o hasta «detener», y su altura es una constante más (regla D). Ver la discusión.

Las cuatro clases de veredicto: equivalente (mismo grafo); equivalente módulo plumbing (difieren solo en un bloque de configuración que una plataforma exige y la otra no); variante (misma idea, una diferencia algorítmica localizada que se describe en una línea); diferente. Los expertos juzgan en cuatro clases; el análisis se hace en cuatro y también colapsado a dos (equivalente / no).

¿Hace falta el grafo?

Sobre el mismo vocabulario canónico caben dos criterios:

• Comparación línea a línea. Cada bloque se traduce a su nodo canónico con las reglas A–D y las dos secuencias se comparan término a término, expresiones incluidas. El veredicto es «iguales» o «distintas, en estas líneas».
• Grafo de dependencias. La comparación actual, que además ignora el orden entre instrucciones independientes (regla E).

La comparación línea a línea es la más estricta: los pares que la pasan tienen también grafos isomorfos. El grafo aporta sobre todo la regla E: desde el 19-09-2026 el eje se compara tal cual y el nombre del dispositivo no llega al grafo; los nombres de las variables del usuario cuentan (en minúsculas). El resto de la normalización vive en la ontología. Para el corpus vigente eso queda cubierto al escribir las actividades, porque las dos versiones se escriben para coincidir y el orden se alinea a mano. El grafo trabaja cuando los dos programas llegan escritos por separado: los pares históricos, las actividades de terceros, los proyectos de estudiantes.

Lo que cambia si el criterio simple basta: la abstracción con LLM produce una secuencia canónica en vez de un grafo con aristas, con menos puntos de falla (aristas de efecto colateral, índices de recurso); la GED, NP-hard y con resultados truncados por tiempo, deja de calcularse; y el veredicto se lee como un diff, «estas dos líneas difieren», que sirve para enseñar.

El corpus: positivos, negativos y controles

El corpus incluye, en proporción parecida, pares que los expertos pueden declarar no equivalentes, porque en un corpus solo de positivos acierta también un juez que dice «sí» a todo. Cada par entra con una etiqueta esperada fijada al armar el corpus (histórico: por el diff en la fuente; fabricado: por el cambio documentado). El corpus se cierra antes del panel. Ningún par se elimina después de etiquetado, porque la selección de pares queda así independiente del resultado. La prevalencia real la fija el panel y se reporta.

Positivos: los 17 pares vigentes

Las versiones actuales de protobject/equivalent-<code>.ptj y microbit/<code>.hex, que la pipeline declara isomorfas (el 19-09-2026: 17/17, GED 0, con los mismos nodos y aristas en cada lado). El 18 y 19-09-2026 el autor las revisó una por una y las alineó por diseño: mismos bloques, en el mismo orden y con los mismos operadores; las diferencias de plataforma quedan solo en los números. Son los positivos esperados.

Negativos naturales: las revisiones anteriores en git

El historial de git guarda cada paso de la refactorización de las actividades hacia la equivalencia, entre fines de julio y mediados de agosto de 2026. Los commits de junio (reorganización y erratas de comentarios) quedan fuera del corpus. Cuentan las versiones distintas por contenido: dos commits de luci-discoteca-ruido restauran una versión anterior y cuentan como una. Doce actividades tienen tres o más versiones del archivo Protobject o del micro:bit. El lado Protobject tiene unas 40 versiones anteriores. El lado micro:bit tiene unas 30. Dos archivos «old» se conservan fuera del historial. Un par histórico se arma con los dos archivos tal como estaban en un mismo commit (git show <commit>:<ruta>) y se etiqueta con la fecha. Los mensajes de commit («fix a music visualizer», «gritometro es ahora equivalente») indican el cambio de cada versión. Estos recuentos y la tabla llegan hasta el 11-09-2026. El 18 y 19-09-2026, al alinear las actividades, cambiaron los 17 archivos Protobject y 13 de los micro:bit; algunas de esas versiones nuevas solo cambian comentarios.

Controles fabricados

Se fabrican variantes a partir de pares vigentes, con un cambio conocido cada una, para saber qué distingue cada juez:

• Casi-equivalentes algorítmicas (esperado: variante o diferente): cambiar un operador (+ por ×), quitar o agregar un bloque dentro del bucle, usar dos ejes del sensor donde el otro usa uno, leer el otro eje (y donde el otro lee x; regla B desde el 19-09-2026), mover una instrucción fuera del bucle. Dos casos reales: al alinear las actividades, el 18 y 19-09-2026, el autor descartó agregar bloques «retraso de 400» en un solo lado (16.5) y cambiar el signo en un solo lado («100 − x» en lugar de «x + 100», 16.7), porque ya no serían equivalentes algorítmicamente: un bloque de más en un lado; un operador distinto (regla D).
• Solo plumbing (esperado: equivalente): reordenar dos instrucciones independientes, cambiar una constante de calibración (p. ej., quitar la compensación de los 400 ms: «retraso de 900» → «retraso de 500» en el Protobject de 02.1, igual que la «pausa 500» del micro:bit), renombrar la instancia del dispositivo, cambiar el color del LED.
• Pares cruzados (esperado: diferente): la versión Protobject de una actividad con la micro:bit de otra parecida (los dos xilófonos; las dos luces al ruido).

El corpus tiene 40–60 pares de al menos 12 actividades distintas. La etiqueta esperada está equilibrada. Tres estratos se analizan por separado: vigentes, históricos y fabricados. Los pares cruzados quedan fuera del kappa principal y se reportan como control de sanidad (acierto esperado cercano al 100 %). Presentación ciega: código de par, orden aleatorio distinto por juez, sin fecha ni procedencia, ambas versiones mostradas como programas de bloques (capturas renderizadas desde la fuente) y también como texto extraído, registrando cuál usó cada juez (P2).

El panel de expertos

1. Composición. Personas que enseñan o investigan programación por bloques y pueden leer MakeCode y Protobject tras una introducción de media hora. Cuatro como objetivo, porque con tres un solo cambio de opinión cambia la mayoría. Tres como mínimo. Quedan fuera del panel quienes construyeron la pipeline o refactorizaron las actividades.
2. Juicio libre, antes de las reglas. Sobre cinco pares (uno por tipo), cada experto responde sin especificación: «¿dirías que son el mismo programa? ¿por qué?». La respuesta se guarda. Mide cuánto de la equivalencia la crean las reglas.
3. Calibración (1 sesión). Se lee la especificación en conjunto; se juzgan tres pares de práctica —uno de cada tipo— y se discuten hasta entender las reglas igual. Los pares de práctica quedan fuera del corpus. Las dudas se registran: son hallazgos sobre la especificación.
4. Juicio independiente y ciego. Cada experto, por su cuenta, para cada par: veredicto (cuatro clases), confianza (1–5), reglas que aplicó, justificación de una o dos líneas, tiempo aproximado. Sin conversar entre ellos hasta terminar.
5. Acuerdo entre expertos. Antes de discutir nada se calcula la fiabilidad entre jueces (§ 07). Ese número se reporta tal cual: mide cuán clara es la especificación.
6. Resolución de desacuerdos (adjudicación). Los pares con desacuerdo se discuten en una reunión con guion fijo. La modera una persona sin acceso a los veredictos de la pipeline ni al archivo de variantes, que no vota. Cada par recibe una etiqueta de consenso (o de mayoría, y se anota). La etiqueta final es la etiqueta de oro. Se sella —archivo con hash y fecha— antes de las corridas automáticas. Las razones de cada cambio de opinión se escriben.

Todo lo que los expertos escriben es dato: sus justificaciones muestran qué criterios usan además de la especificación. Los criterios sobre constantes o tipo de sonido alimentan la página de constantes y unidades.

Las condiciones automáticas

Tres condiciones se comparan contra la etiqueta de oro, porque responden a preguntas distintas.

Cada condición se corre al menos tres veces sobre todo el corpus, porque la abstracción y el juicio directo son estocásticos. La variabilidad entre corridas se reporta como resultado. Las corridas son ciegas a la etiqueta de oro. Se congela por escrito la versión de prompt.md (hash), el modelo y sus parámetros de muestreo. La ontología se trata en dos niveles: (1) una ontología nueva, distinta de la vigente, construida a ciegas sobre el corpus completo y congelada, con tres corridas de abstracción sobre ella, que miden la consistencia de la abstracción; (2) tres reconstrucciones de la ontología, que miden su variabilidad (qué nodos cambian), reportada aparte.

Qué se mide

• Fiabilidad entre expertos, antes de la resolución de desacuerdos: alfa de Krippendorff (sirve para más de dos jueces y datos nominales) y, por pares de jueces, kappa de Cohen. Intervalo de confianza por bootstrap por conglomerado: se remuestrean actividades, porque los pares de una misma actividad son dependientes; se reporta el número de actividades distintas junto al de pares.
• Acuerdo de cada condición automática con la etiqueta de oro: kappa (binario como análisis principal; cuatro clases como secundario), matriz de confusión, y para el binario sensibilidad (detección de los no equivalentes) y especificidad (respeto de los equivalentes), por estrato. Criterio de éxito, escrito y fechado antes de la primera corrida (propuesta): kappa binario ≥ 0,6 con límite inferior del intervalo ≥ 0,4 y sensibilidad ≥ 0,8; si no se alcanza, el resultado se reporta como negativo y la especificación no se ajusta hasta alcanzarlo.
• Aporte del grafo: acuerdo con la etiqueta de oro del criterio línea a línea y del criterio con grafo, por separado, y lista de los pares en que difieren entre sí. Ese recuento dice cuánto agrega el grafo sobre el corpus.
• Consistencia entre corridas de cada condición: proporción de pares con el mismo veredicto en las tres corridas.
• Análisis de desacuerdos: cada par donde la etiqueta de oro y la condición difieren se explica en una línea que nombra la regla implicada (A–E, estructura, o «fuera de la especificación»). El recuento por regla orienta la revisión de la pipeline.
• Lo que los expertos agregan: criterios que aparecen en las justificaciones y faltan en la especificación. Es la lista de candidatos a reglas nuevas, o a dimensiones distintas de la algorítmica.

Amenazas a la validez, y qué se hace

Pasos, en secuencia

1. Especificación para personas. Una página, reglas A–E con ejemplo, cuatro clases, glosario de correspondencias. Septiembre.
2. Corpus histórico. Exportar de git las versiones distintas por commit, armar los pares (máximo tres o cuatro por actividad), verificar cada uno en la fuente, escribir la etiqueta esperada a partir del diff, renderizar las capturas de bloques y extraer el texto, asignar códigos. Septiembre–octubre.
3. Variantes fabricadas. Diez a quince, con el cambio documentado en un archivo cerrado al panel. Octubre.
4. Panel. Reclutar, preparar el material, y luego: juicio libre, calibración, juicio independiente, cálculo de fiabilidad, resolución de desacuerdos, etiqueta de oro sellada. Octubre–inicios de noviembre.
5. Extensión de la pipeline y corridas automáticas. Primero, que la pipeline acepte pares con identificador propio; luego ontología a ciegas congelada, pipeline ×3, reconstrucciones de ontología ×3, LLM-juez ×3 por modelo (texto y bloques), todo ciego y con parámetros escritos. Noviembre.
6. Análisis. Métricas de § 07, tabla de desacuerdos por regla, lista de criterios que los expertos agregan. Noviembre–diciembre.
7. Propuestas de revisión de la especificación. Qué regla cambia, qué se agrega, qué queda para la dimensión experiencial. Diciembre.
8. Borrador del manuscrito. Diciembre.

Preguntas abiertas

1. ¿La pipeline adopta la comparación línea a línea como primer criterio? Propuesta: sí para el corpus co-diseñado, con el grafo para los pares que salgan distintos; la decisión final sale del recuento de § 07.
2. ¿Los expertos ven los bloques, el texto extraído, o ambos? Bloques prueba la pipeline entera (incluida la extracción); texto prueba solo la abstracción. Propuesta: ambos, registrando cuál usó cada juez, para separar en el análisis el efecto de la representación del efecto del juez.
3. ¿Cuatro clases o dos? Propuesta: se juzga en cuatro, se analiza en ambas. Una fiabilidad baja en cuatro clases y alta en dos es un resultado sobre la distinción «módulo plumbing» / «variante».
4. ¿La regla D (las constantes no cuentan) va en la especificación tal cual? Ver la página. Propuesta: va tal cual, y además se le pide al experto que marque si una constante le parece relevante, para saber cuántas veces disiente de la regla aun aplicándola. Desde el 18 y 19-09-2026 la pregunta pesa más: en los 17 pares, el autor dejó las diferencias entre plataformas solo en los números (unidades de los sensores, los 400 ms, alturas, umbrales).
5. ¿La altura del tono como constante (regla D) va tal cual? Misma página. Propuesta: tal cual en la especificación, con la misma marca de disenso.
6. ¿Se le pide al panel un segundo juicio sobre la dimensión interactiva? Una casilla: «¿las mismas entradas producen las mismas salidas?». Da un primer dato para O3. Propuesta: sí.
7. ¿Cuántos pares y cuántos expertos? Propuesta: 40–60 pares de ≥ 12 actividades, 4 expertos (5 si se consigue), 3 como mínimo. Con 3 expertos y 30 pares el resultado es un estudio piloto y el manuscrito se enmarca así.
8. ¿Qué perfil cuenta como experto? Propuesta: docentes o investigadores en enseñanza de la programación; estudiantes de posgrado del área si han enseñado. Quedan excluidos los estudiantes de pregrado.
9. ¿Se compara también contra los veredictos que la pipeline dio en su momento a las versiones históricas? Propuesta: como nota, fuera de las condiciones principales, porque mezcla versiones distintas del decodificador, de la ontología y, desde el 19-09-2026, de las reglas.
10. ¿Dónde termina el glosario y empieza la ontología? Propuesta: el glosario nombra los bloques y componentes (qué es «esperar», qué es «Inclinación»); no dice qué es equivalente a qué.

Puntos de partida

Cinco campos de la literatura: la fiabilidad entre jueces (cómo se mide el acuerdo), la validación de jueces automáticos contra humanos, la detección de clones y la equivalencia de programas (qué significa «el mismo programa» en ingeniería de software), el análisis de programas por bloques y la construcción de corpus anotados. Referencias verificadas, cada una con su uso.

Acuerdo entre jueces

• Jacob Cohen (1960). A Coefficient of Agreement for Nominal Scales. Educational and Psychological Measurement, 20(1), 37-46. doi:10.1177/001316446002000104El kappa original: acuerdo entre dos jueces corregido por azar.verificado en línea · 11-09-2026
• J. Richard Landis, Gary G. Koch (1977). The Measurement of Observer Agreement for Categorical Data. Biometrics, 33(1), 159-174. doi:10.2307/2529310La tabla de interpretación de kappa que todo el mundo cita —y que conviene usar con cautela, como advierten sus autores.verificado en línea · 11-09-2026
• Klaus Krippendorff (2011). Computing Krippendorff's Alpha-Reliability. University of Pennsylvania ScholarlyCommons, Departmental Papers (ASC), Annenberg School for Communication (working paper / postprint, fechado 25-01-2011). http://repository.upenn.edu/asc_papers/43Alfa: para más de dos jueces, datos nominales y datos faltantes. Es la medida principal para el panel.verificado en línea · 11-09-2026
• Ron Artstein, Massimo Poesio (2008). Survey Article: Inter-Coder Agreement for Computational Linguistics. Computational Linguistics (MIT Press / ACL Anthology J08-4004), 34(4), 555-596. doi:10.1162/coli.07-034-R2La guía completa: qué coeficiente usar, qué reportar, cómo interpretar el desacuerdo como información sobre las guías de anotación.verificado en línea · 11-09-2026
• Kevin A. Hallgren (2012). Computing Inter-Rater Reliability for Observational Data: An Overview and Tutorial. Tutorials in Quantitative Methods for Psychology, 8(1), 23-34. doi:10.20982/tqmp.08.1.p023Tutorial práctico con ejemplos de cálculo.verificado en línea · 11-09-2026
• Mary L. McHugh (2012). Interrater reliability: the kappa statistic. Biochemia Medica, 22(3), 276-282. doi:10.11613/BM.2012.031Límites de kappa (prevalencia, número de categorías): por qué se reporta también la matriz de confusión.verificado en línea · 11-09-2026

Jueces automáticos contra humanos

• Lianmin Zheng, Wei-Lin Chiang, Ying Sheng, Siyuan Zhuang, Zhanghao Wu, Yonghao Zhuang, Zi Lin, Zhuohan Li, Dacheng Li, Eric P. Xing, Hao Zhang, Joseph E. Gonzalez, Ion Stoica (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. Advances in Neural Information Processing Systems 36 (NeurIPS 2023), Datasets and Benchmarks Track, New Orleans, USA, vol. 36, pp. 46595-46623 (arXiv v4, 24 Dec 2023). doi:10.52202/075280-2020Cómo se valida un modelo como juez contra humanos: acuerdo, sesgos de posición y de verbosidad, límites. El diseño de referencia para nuestras condiciones automáticas.verificado en línea · 11-09-2026
• Fabrizio Gilardi, Meysam Alizadeh, Maël Kubli (2023). ChatGPT outperforms crowd workers for text-annotation tasks. Proceedings of the National Academy of Sciences (PNAS), 120(30), e2305016120 (online 18 Jul 2023; print 25 Jul 2023). doi:10.1073/pnas.2305016120Comparación de anotación por modelo y por personas: acuerdo con expertos y consistencia entre corridas; nuestro análisis de consistencia sigue este modelo.verificado en línea · 11-09-2026
• Cheng-Han Chiang, Hung-yi Lee (2023). Can Large Language Models Be an Alternative to Human Evaluations?. Proceedings of the 61st Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), Toronto, Canada, ACL, pp. 15607-15631. doi:10.18653/v1/2023.acl-long.870Cuándo un modelo puede sustituir la evaluación humana y cuándo no; útil para escribir las limitaciones.verificado en línea · 11-09-2026
• Anjiang Wei, Jiannan Cao, Ran Li, Hongyu Chen, Yuhui Zhang, Ziheng Wang, Yuan Liu, Thiago S. F. X. Teixeira, Diyi Yang, Ke Wang, Alex Aiken (2025). EquiBench: Benchmarking Large Language Models' Reasoning about Program Semantics via Equivalence Checking. Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing (EMNLP 2025), Suzhou, China, ACL, pp. 33868-33881 (arXiv v3, 19 Sep 2025). doi:10.18653/v1/2025.emnlp-main.1718Benchmark de equivalencia de programas para modelos de lenguaje: la tarea más cercana a la nuestra, y la evidencia de que los modelos tienden a juzgar por similitud sintáctica. Lectura obligatoria.verificado en línea · 11-09-2026

Clones y equivalencia de programas

• Chanchal Kumar Roy; James R. Cordy (2007). A Survey on Software Clone Detection Research. Technical Report No. 2007-541, School of Computing, Queen's University at Kingston, Ontario, Canada, 115 pp. (dated September 26, 2007). research.cs.queensu.ca/TechReports/Reports/2007-541.pdfLos cuatro tipos de clon: el tipo 2 (idénticos salvo identificadores y literales) es donde se ubica la regla D; el tipo 4 (semántico) es el objetivo de la pipeline.verificado en línea · 11-09-2026
• Chanchal K. Roy; James R. Cordy; Rainer Koschke (2009). Comparison and evaluation of code clone detection techniques and tools: A qualitative approach. Science of Computer Programming (Elsevier), 74(7), 470–495. doi:10.1016/j.scico.2009.02.007Escenarios de edición para evaluar detectores de clones: la plantilla de nuestras variantes fabricadas.verificado en línea · 11-09-2026
• Jeffrey Svajlenko; Judith F. Islam; Iman Keivanloo; Chanchal K. Roy; Mohammad Mamun Mia (2014). Towards a Big Data Curated Benchmark of Inter-project Code Clones. 2014 IEEE International Conference on Software Maintenance and Evolution (ICSME), Victoria, BC, Canada. IEEE, pp. 476–480. doi:10.1109/ICSME.2014.77Cómo se construyó un benchmark de clones con etiquetas humanas y jueces múltiples.verificado en línea · 11-09-2026
• Luigi P. Cordella; Pasquale Foggia; Carlo Sansone; Mario Vento (2004). A (Sub)Graph Isomorphism Algorithm for Matching Large Graphs. IEEE Transactions on Pattern Analysis and Machine Intelligence, 26(10), 1367–1372. doi:10.1109/TPAMI.2004.75VF2, el algoritmo que decide el isomorfismo en la pipeline.verificado en línea · 11-09-2026
• Armando Solar-Lezama (2008). Program Synthesis By Sketching. PhD thesis, EECS Department, University of California, Berkeley; Technical Report No. UCB/EECS-2008-176, Tech. Rep. UCB/EECS-2008-176, diciembre 2008. www2.eecs.berkeley.edu/Pubs/TechRpts/2008/EECS-2008-176.htmlEl sketch: «mismo esqueleto, constantes por determinar», formalizado.verificado en línea · 11-09-2026

Programas por bloques

• Jesús Moreno-León; Gregorio Robles (2015). Dr. Scratch: a Web Tool to Automatically Evaluate Scratch Projects. Proceedings of the Workshop in Primary and Secondary Computing Education (WiPSCE '15), London, UK. ACM, pp. 132–133 (poster, 2 páginas). doi:10.1145/2818314.2818338Análisis automático de proyectos por bloques: qué se puede medir de un programa de bloques sin ejecutarlo.verificado en línea · 11-09-2026
• Efthimia Aivaloglou; Felienne Hermans (2016). How Kids Code and How We Know: An Exploratory Study on the Scratch Repository. Proceedings of the 2016 ACM Conference on International Computing Education Research (ICER '16), Melbourne, VIC, Australia. ACM, pp. 53–61. doi:10.1145/2960310.2960325Cómo programan los niños en Scratch, a escala: base para saber qué variantes son realistas.verificado en línea · 11-09-2026

Construir un corpus anotado

• James Pustejovsky, Amber Stubbs (2012). Natural Language Annotation for Machine Learning: A Guide to Corpus-Building for Applications. O'Reilly Media, Sebastopol, CA (libro, 1.ª ed.), 342 pp. (publicado 11 Oct 2012). www.oreilly.com/library/view/natural-language-annotation/9781449332693/Guías de anotación y el ciclo modelar–anotar–evaluar: la especificación de § 03 es, técnicamente, una guía de anotación.verificado en línea · 11-09-2026