Estudio: reporte de la campaña de renombrado tier-true — el registro completo y la ruta

Estado: FINAL para la etapa 1 (ensayo en VERDE, 2026-08-16). Este es el reporte completo que ordenó el operador: todo lo hecho, cómo se hizo, los agentes y sus instrucciones, la maquinaria de mediación, la telemetría, y la ruta generalizada para trabajo de refactorización futuro en este o en cualquier proyecto. Documentos acompañantes: el estudio del ensayo docs/research/tier-true-rename-rehearsal-2026-08-16.md, el plan de campaña docs/planning/TIER-TRUE-RENAME-CAMPAIGN.md, la tesis docs/research/language-as-architecture-thesis-v2.md, y las mediciones docs/research/e2-name-comprehension-2026-08-16.md y docs/research/doc-audit-study-2026-08-16.md.

Resumen

Renombramos las 394 piezas de este taller para que cada nombre declare la capa arquitectónica verdadera de la pieza — y lo hicimos sin editar a mano un solo archivo. El renombrado se planeó como 35,879 renglones de base de datos (uno por cada lugar donde aparece un nombre), aplicados por un programa deliberadamente simple que verifica cada renglón antes de reemplazarlo, dentro de una copia desechable del repositorio. La copia se compiló, se probó y se pasó por el comprobador de documentación; cada falla se convirtió en una clase con nombre y una regla con prueba dentro de las herramientas, y la copia se tiró y se regeneró hasta que salió verde. Está verde: el mundo renombrado compila, sus 394 suites de pruebas pasan, y su registro de capas es consistente. Nada se ha fusionado — la copia verde y este reporte son la evidencia sobre la que resuelve el operador. La razón del trabajo: la medición E2 mostró que los nombres viejos desinforman activamente a los modelos de lenguaje (los modelos leen el prefijo de marca como una afirmación arquitectónica y responden mal), mientras que los nombres tier-true se entienden sin ningún contexto extra. Los nombres correctos son el contexto más barato que existe.

Diagramas

La campaña de punta a punta:

flowchart LR
    E2[medir: prueba E2 de comprensión\nsolo con el nombre] --> RULE[resolución del operador:\nrenombrar, por etapas]
    MOCK[costear: simulacro de piezas en la base\n35,879 sitios de referencia] --> RULE
    RULE --> PLAN[(renglones rename_edit\nplan como datos)]
    PLAN --> EXPORT[aplicador: verificar\ny luego reemplazar]
    EXPORT --> WT[árbol de ensayo\ncopia desechable]
    WT --> PROBES[sondas: build, test,\ndoc-truth, check-deps]
    PROBES -->|clase de falla| RULES[regla con prueba en el\nplaneador o el aplicador]
    RULES --> PLAN
    PROBES -->|VERDE| GATE[puerta de fusión etapa 2:\nresolución del operador]

El ciclo de iterar-hasta-verde que produjo el resultado:

flowchart TD
    R[reproducir renglones en una copia nueva] --> P{sonda}
    P -->|rojo| C[nombrar la CLASE de falla]
    C --> T[escribir una regla CON PRUEBA en la herramienta\nnunca editar la copia a mano]
    T --> R
    P -->|verde| V[veredicto + rendición de cuentas\nde cada renglón rechazado]

Rondas hasta el verde (renglones aplicados y estado de sondas por ronda):

flowchart LR
    r1[R1-4: reglas de exportación\n~30,700 aplicados] --> r5[R5-6: build en rojo\nclases TOML + gramática rs]
    r5 --> r7[R7: build VERDE\ntest en rojo: include_str]
    r7 --> r8[R8: replanear +3,185 renglones\nclases md + registro]
    r8 --> r9[R9: 33,931 aplicados\nbuild VERDE]
    r9 --> r10[R10: tests VERDE\ncapas VERDE -> VEREDICTO]

Qué se hizo, en orden

1. Se midió el problema (E2). 41 piezas, clasificación de capa solo con el nombre, dos niveles de modelo. Nombres actuales: 24/41 (haiku), 16/41 (sonnet), y 28 de 82 respuestas leyeron mal el prefijo de marca como si significara «fundacional». Nombres tier-true: 41/41 en los dos niveles. Conclusión: los nombres inyectan hechos falsos; renombrar quita una fuente permanente de error del modelo y el contexto que se gasta corrigiéndola. 2. Se costeó el renombrado en la base de datos antes de tocar nada. El simulacro de piezas (crate_desired_state, 394 nombres destino) contó cada clase de referencia desde el espejo del corpus: manifiestos dependientes, identificadores en el código, menciones en documentación, renglones de registro, candados de repositorios consumidores. El costo para los consumidores se redujo a 128 alias de una línea package = en 12 repositorios. La decisión de renombrar se tomó con esos dos números juntos — beneficio (E2) y costo (simulacro) — no por gusto. 3. Se planeó el renombrado como datos. tools-org-knowledge corpus rename-plan escribió un renglón rename_edit por sitio: archivo, línea, texto antes, texto después, clase de edición. Plan final: 35,879 renglones (registro 12,988 · doc_ref 10,388 · ident 6,959 · otros 3,539 · manifiesto 2,005). 4. Aplicado por un exportador deliberadamente simple. rename-export se niega a correr en cualquier lado que no sea un árbol de trabajo nombrado, verifica cada renglón contra el contenido actual del archivo antes de reemplazar (palabra completa, con conciencia de la gramática), rechaza en voz alta cuando un renglón está viejo, e imprime una taxonomía de cada rechazo. Reproducible: los mismos renglones, el mismo resultado. 5. Se sondeó y se iteró. 10 rondas (más una regresión de plan descartada). Cada sonda roja se convirtió en una clase de falla y una regla con prueba en el planeador o el aplicador — nunca en una edición a mano en la copia. La tabla completa de clases con sus commits está en el estudio del ensayo. 6. Veredicto VERDE, con cada renglón rechazado clasificado (1,948 viejos = rechazos correctos: rutas que no deben renombrarse, componentes compuestos, líneas ya editadas) y una lista de seis puntos para el momento de la fusión en la etapa 2.

Antes / después

Ejemplos de nombres (el prefijo de capa carga la clasificación):

Comprensión medida (E2):

Comparación de procesos:

Agentes usados y sus instrucciones

Dos agentes hicieron este trabajo, coordinados por paso de mensajes; un solo dueño por archivo en todo momento.

1. Coordinador (esta sesión). Sostuvo las restricciones del operador, resolvió preguntas de alcance, retransmitió los puntos de control y nunca editó archivos propiedad de la bifurcación. También redactó el plan de campaña, la tesis v2 y este reporte. 2. Bifurcación del ensayo (agente en segundo plano, con su carta fijada al crearse): ser dueña del lote rename_edit y del árbol de trabajo del ensayo; iterar exportar→sondear hasta el verde; registrar telemetría por ronda; escribir el estudio; nunca fusionar, empujar ni presentar la rama como si estuviera en juego. Las directivas del coordinador hacia ella durante la corrida, textuales:

«El operador ha puesto el ensayo de renombrado como el asunto de máxima atención. Continúa iterando hasta el verde sin pausar entre rondas. […] sigue registrando la telemetría de cada ronda en la serie tier-true-rename-2026-08-16 y mantén el documento del estudio al día sobre la marcha, no al final. Restricciones sin cambio: solo el árbol de trabajo, solo experimento, sin fusionar, empujar ni usar el resultado.»

«Directiva del operador: continúa hasta el verde y entrega el veredicto final. Corre las rondas una tras otra hasta que las sondas estén verdes (build + test + tools-doc-truth clasificado + capas), y luego reporta el veredicto final exactamente en esta forma: (1) línea de veredicto […] (7) ruta del documento del estudio + hash del commit final en la rama del ensayo.»

«Directiva del operador: el objetivo del resultado es VERDE — sigue iterando hasta ganártelo. Eso significa: vuelve a correr la prueba inestable en un equipo tranquilo; si pasa de forma consistente (3 veces), regístralo como contención y declara la suite verde. Si falla de forma determinista, es una clase de falla real — nómbrala, añade la regla con prueba, vuelve a exportar, vuelve a sondear, y sigue hasta el verde. No declares verde nada que no esté demostrado; el veredicto tiene que sobrevivir a que el operador corra las sondas él mismo.»

La última directiva es el contrato de honestidad en un párrafo: el verde es una medición, no una declaración. La disciplina de la propia bifurcación estuvo a la altura — retiró un «verde» de la ronda 5 cuando descubrió que una tubería había enmascarado una compilación roja, y volvió a correr su suite final en un equipo tranquilo en vez de dar por decisiva una corrida con contención.

Fragmentación y mediación semántica

La campaña corrió sobre la pila de mediación construida en los sprints 4.8–4.11:

• Registros ratificados como fuentes únicas. tier-vocabulary.tsv (las seis

capas), lexicon.tsv, doc-skeletons.tsv, noun-senses.tsv, model-routing.tsv. Los nombres destino del renombrado se derivan del vocabulario de capas ratificado — el renombrado es el registro proyectado sobre el espacio de nombres de las piezas.

• Detectores mecánicos (D9–D14) con líneas base que solo encogen. La misma

corrida de tools-doc-truth que vigila cada commit vigiló el árbol renombrado; sus 374 hallazgos residuales se atribuyeron clase por clase en vez de dejarse pasar.

• Enganches a nivel de palabra en la ruta de escritura. El hook de léxico previo

al commit rechazó una metáfora prohibida en el propio borrador de la tesis de esta campaña, minutos antes de que se escribiera este reporte (la palabra rechazada se cita abajo con atribución) — la maquinaria vigila a sus propios autores, que es el punto. Término rechazado: load-bearing; reemplazo: «entradas del modelo tratadas como hechos».

• Renglones de plan como fragmentos. Cada renglón rename_edit es una unidad

libre de criterio que un programa puede verificar de forma independiente — el mismo principio de fragmentación que los fragmentos byte a byte con huella de contenido de la auditoría de documentación, aplicado a ediciones en vez de a instrucciones. El criterio del modelo se gastó solo donde corresponde: nombrar clases de falla y escribir reglas. Contar, emparejar y reemplazar fue código (regla 14 del operador: la IA nunca cuenta lo que puede contar el código).

• Un sustantivo un referente, y reemplazo con conciencia de gramática. La

división gramatical de .rs (forma de identificador en el código, forma de paquete en cadenas y comentarios) y el escudo con forma de ruta son mediación semántica al nivel del carácter: el aplicador decide qué SIGNIFICA un componente en su posición antes de poder reemplazarlo.

Telemetría

Serie completa tier-true-rename-2026-08-16 en run_measurement (con procedencia en cada renglón); criterio de inestabilidad: 3 pasadas aisladas en un equipo tranquilo = contención:

Final: 33,931 aplicados · 1,948 viejos (ruta de miembro 212, protegidos por forma de ruta 378, componente incrustado 881, sombreados o con desfase de línea 477) · 0 perdidos · 6/6 pasadas de aislamiento de la inestable · ~1.1 h de tiempo de ronda registrado · commit del ensayo 07de7d57 en rehearse/tier-true-rename.

Por qué esto sirve al objetivo de la programación lingüística

El objetivo (intención textual del operador): corrección del lenguaje para que el modelo necesite menos contexto para acertar. Esta campaña es ese objetivo ejecutado al nivel del espacio de nombres:

1. Los nombres se volvieron hechos. Después del renombrado, leer el nombre de una pieza ES leer su clasificación arquitectónica — sin documento de preparación, sin adivinar, sin afirmación de marca malinterpretada. E2 mide la ganancia: 100 % de comprensión solo con el nombre, arriba del 41–61 %, y sin el patrón de desinformación. 2. El vocabulario se impone, no se aspira. Los registros alimentan detectores; los detectores vigilan los commits; las líneas base solo encogen. La deriva es una comprobación que falla, no un comentario de revisión. 3. El método de refactorización es él mismo lingüístico. Las clases de falla se NOMBRAN; los renglones viejos llevan una taxonomía; las reglas son frases con prueba sobre qué significa un componente en una posición. Los artefactos de la campaña hablan el mismo vocabulario ratificado que instalan. 4. Hablar sale más barato en el futuro. Toda instrucción futura — humana o del arnés — que nombre una pieza ahora transmite su capa gratis. Este es el sustrato sobre el que el arnés de desarrollo guiado traduce el habla del operador.

Ruta: cómo correr esto en cualquier repositorio

El manual generalizado, cada paso con su condición de salida:

1. Espeja el repositorio en una base de datos (archivos, documentos, dependencias, referencias). Salida: las cuentas de SQL coinciden con comprobaciones puntuales. 2. Mide el defecto lingüístico con un experimento de modelo real (el patrón E2: tareas solo con el nombre, dos niveles de modelo, calificadas contra la verdad de campo). Salida: un número del daño, no una opinión. 3. Ratifica el vocabulario destino con el dueño humano. Los registros son semillas TSV de fuente única. Salida: una resolución escrita. 4. Costea el cambio en la base de datos antes de cualquier edición: un renglón de estado deseado por artefacto, una cuenta por clase de referencia. Salida: los números de beneficio y de costo lado a lado; resolución de proceder. 5. Planea como renglones: antes y después a nivel de término por sitio, clase de edición por renglón, identificador de lote. Salida: las cuentas por clase cuadran con el simulacro. 6. Construye un aplicador que rechace: barrera de solo-árbol-de-trabajo, verificar-y-luego-reemplazar, palabra completa con conciencia de gramática, taxonomía ruidosa de lo viejo, reproducible. Salida: los mismos renglones dos veces = árbol idéntico. 7. Sondea con la propia maquinaria de verdad del repositorio: compilación, pruebas completas, puertas de documentación y estilo, consistencia del registro — con pipefail en todos lados. Salida: cada rojo nombra una clase. 8. Itera hasta el verde: cada clase se vuelve una regla con prueba en las herramientas; nunca editar a mano el árbol generado; reiniciar y reproducir. Salida: sondas verdes Y cada renglón rechazado clasificado Y una lista escrita para el momento de la fusión. 9. Condiciona la fusión a una resolución humana con el árbol verde, el estudio y la lista en la mano. Salida: el dueño fusiona (o no) — el ensayo nunca se autopromueve. 10. Registra todo como investigación: serie de telemetría por ronda, documento de estudio actualizado en vivo, tabla de clases de falla con commits. Salida: la siguiente campaña empieza desde reglas, no desde recuerdos.

Qué sigue

• Etapa 2 (condicionada por el operador): fusionar = diferencia del ensayo + reasentar

las líneas base + redefinición del hecho D1 + regeneración del espejo + reinstalar los hooks de git + las seis migraciones de mecanismos indexados por prefijo, todo en un cambio.

• Etapa 3: generar las 128 líneas de alias para los consumidores (12 repositorios).
• Etapa 4: migración de la documentación viva a través del ciclo; los archivos

históricos se quedan como historia.

• Investigación: el control reservado (las mismas tareas, nombres viejos contra

nuevos) que sube la tesis v2 de reporte de experiencia a afirmación puesta a prueba.

• Defectos de base sacados a la luz para sus dueños: location.rs sin seguimiento en

master, la inestable BUG-0006, archivos de reporte citados pero sin seguimiento.