yelixir-dev/no-more-dasi-eng

nomoredasi — Corrección de inglés académico adaptada al campo (v0.1)

Habilidad para pulir manuscritos antes de que llegue el "hazlo de nuevo". Corrige manuscritos de investigación a un nivel de inglés adecuado para revistas del grupo Nature. Las convenciones específicas de cada campo (selección léxica, densidad, ritmo, estructura) son gestionadas por references/overlays/<campo>.md, mientras que las reglas comunes a todos los campos son gestionadas por references/core/.

4 principios fundamentales (comunes a todas las rutas, prohibido entregar si se incumplen)

1. Invariabilidad semántica — No se altera el contenido, las afirmaciones ni el orden lógico. Solo se corrigen el estilo y la expresión.
2. Basado en evidencia — Toda corrección se fundamenta en las reglas de references/core/ o en las mediciones del corpus de la superposición del campo correspondiente. No se eliminan expresiones "propias de IA" por intuición.
3. Mantenimiento del género — Se conserva el registro de artículo académico. Prohibido coloquializar o ensayar. Prohibido aplicar reglas de estilo ASD-STE100 (voz activa forzada, límite de 20 palabras por oración, prohibición de -ing) — entran en conflicto con las mediciones reales de las revistas (voz pasiva 111-137/10K, media de oraciones de 16.5-18.3 palabras) (ver references/core/academic-en.md).
4. Prohibición de sobreedición — Si la tasa de cambio supera el 30%, se advierte; si supera el 50%, se detiene y se pide confirmación al usuario. El script scripts/verify_integrity.py determina de forma concluyente.

Fase 0: Identificación del tipo de entrada

Al iniciar el trabajo, se imprime una línea. La etiqueta sigue el idioma de la solicitud del usuario:

• Solicitud en coreano: nomoredasi v0.1 — tipo {A|B} / campo: {campo resuelto}

• Solicitud en inglés: nomoredasi v0.1 — type {A|B} / field: {campo resuelto}

• Otros idiomas: las etiquetas type/field se traducen a ese idioma.

• Tipo A (manuscrito en coreano) — Ruta combinada de traducción + corrección. Primero se detectan las estructuras que inducen a traducción literal en references/core/korean-author-pitfalls.md (p. ej., "a través de", "por medio de") para bloquear la traducción directa, luego se traduce y se aplican las mismas 3 capas de reglas que en el Tipo B.

• Tipo B (manuscrito en inglés, incluidos borradores de IA) — Ruta de corrección. Si hay indicios de borrador de IA, se aplica la capa adicional de references/core/ai-tell-en.md.

Fase 1: Enrutamiento por campo (3 niveles de prioridad)

1. Explícito del usuario — Si el usuario indica el campo, se usa ese.
2. Carpeta — Si el archivo del manuscrito está en una carpeta como papers/<campo>/, se usa ese campo.
3. Detección automática — Se ejecuta scripts/route_field.py <manuscrito>, se usa el resultado principal. Si los dos primeros resultados tienen puntuaciones cercanas, se fusionan ambas superposiciones.
4. Si no está claro, se consulta una vez — Prohibido hacer preguntas abiertas. Se presenta una estimación en forma de "Parece ser Óptica y Fotónica. Si es correcto, continuamos" y se pregunta solo una vez.

Incluso si el campo es incorrecto, las reglas centrales funcionan independientemente del campo, por lo que es seguro. Si no hay archivo de superposición para el campo, se continúa solo con las reglas centrales y se informa de ello. Si el Maturity: en el encabezado de la superposición es immature (archivo <10 o <100K palabras), ese valor numérico se usa solo como referencia direccional, no como objetivo fijo.

Fase 1.5: Archivo de estado del manuscrito (manuscript.json)

Si existe manuscript.json en la carpeta del manuscrito, se lee y se aplica: lista de definiciones de abreviaturas, notación terminológica confirmada (p. ej., bandgap), lista de figuras. Es un mecanismo para mantener la coherencia general del documento en correcciones parciales o solicitudes repetidas. Si no existe, se continúa sin crearlo, pero después de entregar la corrección, se ejecuta scripts/manuscript_state.py learn <carpeta> <corregido> para registrar las decisiones del día (abreviaturas definidas, notaciones mayoritarias). Las nuevas observaciones que entren en conflicto con valores existentes no se sobrescriben, sino que se informan al usuario.

Fase 2: route_hint — 3 rutas de intensidad de corrección

Se examina el borrador y se decide entre light / standard / heavy, y se imprime la decisión. Durante la corrección, según las reglas de la Fase 3 a continuación, se escribe siempre el diario <corregido>.edits.json de forma incremental por secciones.

• light (1 pasada) — Manuscrito ya bien escrito (estilo publicable, solo errores gramaticales esporádicos). Solo se corrigen las violaciones de las reglas centrales. Tasa de cambio mínima.
• standard (2 pasadas) — Caso general. Pasada 1: reglas de las 3 capas centrales (① Inglés académico general — tiempos, artículos, concordancia numérica ② Unificación de notación terminológica del campo — superposición Notation watch ③ Registro de la revista). Pasada 2: autoevaluación + scripts de verificación.
• heavy (3+ pasadas) — Muchas traducciones literales / indicios de IA, torpeza estructural. Pasada 1: preprocesamiento específico del tipo (pitfalls o ai-tell). Pasada 2: reglas de las 3 capas centrales. Pasada 3: pulido del flujo y desarrollo de párrafos. Luego verificación.

Eje de presupuesto de intensidad de corrección (level): route_hint es un diagnóstico del estado del manuscrito (prohibido cambiar, solo juicio del agente), mientras que level es el presupuesto de cambios elegido por el usuario (por defecto bajo/low). Se introduce con verify_integrity.py --level {low,mid,high} (registrado con log_edit.py --level) y aplica umbrales low=bajo/10-30%, mid=medio/20-50%, high=alto/30-50% (no puede ser más fuerte que la puerta interna). Trabajo efectivo = min(diagnóstico, presupuesto) — el presupuesto puede reducir la intensidad requerida por el diagnóstico, pero nunca aumentarla por encima. Si el presupuesto solicitado y el diagnóstico discrepan, se informa explícitamente al usuario (p. ej., "El manuscrito tiene diagnóstico heavy, pero con solicitud baja solo se corrigieron las violaciones centrales"). Para intentar alcanzar un objetivo light en el mismo manuscrito, se requiere una nueva consulta.

Solicitud simultánea de múltiples intensidades: Si el usuario solicita varias intensidades ("bajo y medio", "medio y alto", "los tres"), se realiza corrección, verificación y entrega independientes para cada intensidad. La salida se diferencia como <nombre_manuscrito>.low.md / .mid.md / .high.md, y el diario (edits.json), el informe (HTML) y el registro (log_edit --level) también se generan para cada intensidad.

Fase 3: Corrección con reconocimiento de secciones

El manuscrito se divide con scripts/section_split.py para su reconocimiento (IMRaD + Results and Discussion combinados, variantes como Experimental Section, etc.).

Obligación de escribir el diario (edits.json): Durante la corrección, se escribe <corregido>.edits.json de forma incremental por secciones — cada edición no se rellena después de borrar, sino que se registra junto con los elementos kept (tramos evaluados pero no cambiados). El formato sigue el esquema v1 de scripts/check_journal.py:

• changed — Ediciones que cambiaron un tramo del original (original, corrected del corregido, <40 tokens). Se señala la regla de fundamento con rule: {source, id} y se registra brevemente el motivo en reason.
• kept — Tramos evaluados pero no tocados. Se registran original (presente igual en ambos archivos) y reason. rule es opcional.

original y corrected deben ser subcadenas exactas del manuscrito original y del corregido, respectivamente. No se omiten ediciones de puntuación — la puerta de cobertura del diario verifica mecánicamente que todas las áreas changed/insert/delete del diff estén cubiertas por el diario. Aunque las conferencias y revistas tengan estructuras diferentes, la macroestructura es una selección de resumen/introducción/cuerpo/resultados/conclusión, y las formas combinadas (Results+Discussion, cuerpo+resultados) no son errores, por lo que no se "normalizan" con la corrección. Las reglas de tiempos verbales, voz pasiva, desarrollo y ritmo por sección siguen references/core/academic-en.md §3 y §8.

• Methods = se mantiene el predominio de pasado y voz pasiva (prohibido forzar la voz activa)
• Results = centrado en pasado, presente para referencias a figuras. No se insertan oraciones interpretativas en Results
• Discussion/Conclusion = interpretación en tiempo presente
• Abstract = forma abreviada de la sección, se aplican reglas de mezcla de tiempos
• En Introduction no se crea estructura de conclusión (§8 verificación de contaminación cruzada) — agregar elementos como "in conclusion" en la introducción viola la invariancia semántica

Solicitud de corrección parcial ("solo la introducción", "solo el cuerpo")

Si el usuario solicita solo una sección específica, se bloquea el alcance: solo se corrige la sección solicitada, las demás no se tocan. Se mantiene el rol de esa sección (§8), no se aplican reglas de secciones ausentes, y las referencias cruzadas ("Sección 3", "Figura 4") no se editan, solo se informan las referencias rotas como nota. La puerta de verificación también se ejecuta basándose en ese intervalo (academic-en.md §9).

Fase 4: Verificación (puertas de código — prohibida la autoevaluación del LLM)

Ejecución de pruebas: Incluso en consolas no UTF-8 (p. ej., Windows coreano cp949), el conjunto de pruebas especifica la codificación, por lo que se ejecuta sin variables de entorno.

Antes de la entrega, se deben ejecutar los siguientes pasos e informar los resultados (en orden desde la puerta 0 — si una puerta anterior sale con exit 1, se prohíbe la entrega posterior):

0. scripts/check_journal.py <original> <corregido> --journal <corregido>.edits.json — Puerta de cobertura del diario (si todas las áreas de cambio del diff están cubiertas por el diario, tramos ≤40 tokens, rule.id existe en rule.source). Si exit 1, se bloquea la entrega — se deben añadir las ediciones/elementos kept faltantes al diario o dividir los tramos, y volver a ejecutar.

1. scripts/verify_integrity.py <original> <corregido> --repeat 2 --report <corregido>.integrity-report.html — Preservación de números, unidades, fórmulas químicas, citas, ecuaciones, DOI (＋con --overlay también terminología especializada) + puerta de tasa de cambio. Si exit 1, se prohíbe la entrega, se corrigen las infracciones y se vuelve a ejecutar. El archivo de informe (<corregido>.integrity-report.html) se entrega junto con el corregido para que el usuario pueda revisar los cambios mediante diff.

2. scripts/check_terms.py <corregido> — Consistencia en la notación de términos (bandgap/band gap, etc.). Si exit 1, se unifica a la forma mayoritaria y se vuelve a ejecutar.

3. scripts/check_abbrev.py <corregido> [--state <carpeta>] — Detección de abreviaturas no definidas. Si exit 1, se añade la definición en la primera aparición o se contrasta con manuscript.json. Las abreviaturas no verificadas (aquellas de las que se desconoce el desarrollo) se registran en el registro con scripts/abbrev_registry.py references/abbrev-registry.json record <ABBR> --field <campo> --context <oración>. Si posteriormente se observa el desarrollo de la misma abreviatura en textos del mismo campo (scan), se actualiza a verificada junto con la oración de contexto; si se observa un desarrollo diferente, se marca como conflicto y se solicita confirmación al usuario. La vista para humanos es references/abbrev-registry.html (regenerado automáticamente, prohibido editar; SSOT es json).

4. Si es una corrección parcial, las pruebas anteriores se ejecutan basándose en ese intervalo.

Al entregar, se ejecuta scripts/log_edit.py <campo> <route_hint> <A|B> <original> <corregido> [--journal <corregido>.edits.json] para registrar el par de corrección (y el diario, si se inserta) en logs/edits/ (medición de referencia de calidad, canalización de pitfalls, entrada del diario de por qué se cambió).

Medición de calidad (para la mejora de la propia habilidad)

scripts/bench_edit.py <original> <corregido> — Compara las infracciones/100 palabras (indicios de IA, hedging anidado, modificadores exagerados, tiempos de figuras, oraciones largas, densidad de adverbios de transición, inconsistencia de notación) antes y después de la corrección. No es una puerta de entrega, sino un mecanismo de medición del rendimiento de la habilidad: en los ciclos delta mensuales/semanales, se aplica a casos golden y a registros de corrección reales; si la tasa de infracciones retrocede (exit 1), se revierten los cambios en la superposición/reglas.

Archivos de referencia

• references/core/academic-en.md — Tiempos verbales, artículos, equilibrio de voz pasiva, adverbios de transición, hedging (comunes a todos los campos)
• references/core/ai-tell-en.md — Patrones de detección de borradores de IA en inglés (incluye fundamentos de no aparición en revistas)
• references/core/korean-author-pitfalls.md — Diccionario previo de errores de hablantes de coreano (primera edición, crece con acumulación de diff)
• references/overlays/<campo>.md — Mediciones específicas del campo: indicadores de estilo, terminología principal, banco de frases, lista de vigilancia de notación. Generado automáticamente por scripts/mine_corpus.py desde ~/Documents/papers/<campo>/, actualizado dos veces por semana.

Lo que no se hace

• Añadir, eliminar o reestructurar contenido (violación de invariancia semántica)
• Aplicar reglas de simplificación no académicas como ASD-STE100, Plain English
• Preguntar al usuario con preguntas abiertas sin conocer el campo
• Informar solo con "se ha verificado" sin scripts de verificación