yelixir-dev/no-more-dasi-eng

nomoredasi — Compétence de correction académique en anglais adaptée au domaine (v0.1)

Compétence pour peaufiner avant d'entendre « refais-le ». Corrige un manuscrit d'article au niveau d'anglais requis pour une soumission dans une revue de la famille Nature. Les pratiques spécifiques au domaine (choix de mots, densité, rythme, style de développement) sont gérées par references/overlays/<domaine>.md, et les règles communes à tous les domaines par references/core/.

4 Principes Fondamentaux (communs à tous les chemins, non-respect = interdiction de livraison)

1. Invariance sémantique — Ne pas modifier le contenu, les affirmations ou l'ordre logique. Ne corriger que le style et l'expression.
2. Basé sur des preuves — Toute correction doit se fonder sur une règle de references/core/ ou sur une mesure empirique du corpus de la surcouche du domaine. Ne pas supprimer par intuition des expressions « dignes d'une IA ».
3. Maintien du genre — Conserver le registre académique. Interdiction de rendre le texte oral ou de le transformer en essai. Interdiction d'appliquer les règles de type ASD-STE100 (voix active obligatoire, limite de 20 mots par phrase, interdiction du -ing) — cela entre en conflit avec les mesures observées dans les revues (111-137 formes passives / 10 000 mots, moyenne de 16,5 à 18,3 mots par phrase) (voir references/core/academic-en.md).
4. Pas de surcorrection — Alerter si le taux de modification dépasse 30 % ; s'arrêter et demander confirmation de l'utilisateur au-delà de 50 %. Le script scripts/verify_integrity.py est l'arbitre définitif.

Phase 0 : Identification du type d'entrée

Au début du travail, afficher une ligne. L'étiquette suit la langue de la demande de l'utilisateur :

• Demande en coréen : nomoredasi v0.1 — 유형 {A|B} / 분야: {domaine résolu}

• Demande en anglais : nomoredasi v0.1 — type {A|B} / field: {resolved field}

• Autre langue : traduire les étiquettes type/field dans cette langue.

• Type A (manuscrit coréen) — Chemin combiné traduction + correction. Détecter d'abord les structures de traduction littérale de references/core/korean-author-pitfalls.md (« à travers », « par »…) pour bloquer la traduction mot à mot, puis traduire. Ensuite, appliquer les 3 couches de règles identiques au type B.

• Type B (manuscrit anglais, y compris brouillon IA) — Chemin de correction. Si des signes de brouillon IA sont présents, appliquer la couche references/core/ai-tell-en.md supplémentaire.

Phase 1 : Routage par domaine (3 niveaux de priorité)

1. Explicite de l'utilisateur — Si l'utilisateur indique le domaine, l'utiliser tel quel.
2. Dossier — Si le fichier du manuscrit se trouve dans un dossier nommé papers/<domaine>/, utiliser ce domaine.
3. Détection automatique — Exécuter scripts/route_field.py <manuscrit>, utiliser le premier résultat. Si les deux premiers scores sont proches, fusionner les deux surcouches.
4. En cas d'incertitude, une seule vérification — Interdiction des questions ouvertes. Proposer une estimation sous la forme « Il semble que ce soit Optics and photonics. Si c'est correct, je continue » et ne demander qu'une seule fois.

Même si le domaine est mal identifié, les règles de base fonctionnent indépendamment du domaine, donc c'est sûr. S'il n'existe pas de fichier de surcouche pour ce domaine, procéder avec les seules règles de base et en informer l'utilisateur. Si l'en-tête de la surcouche indique Maturity: immature (moins de 10 fichiers ou moins de 100 000 mots), ces chiffres servent uniquement de référence directionnelle et non de cible absolue.

Phase 1.5 : Fichier d'état du manuscrit (manuscript.json)

Si manuscript.json existe dans le dossier du manuscrit, le lire et le prendre en compte — liste des abréviations définies, orthographe des termes confirmée (ex. bandgap), liste des figures/schémas. C'est un dispositif pour maintenir la cohérence globale du document lors de corrections partielles ou répétées. S'il n'existe pas, ne pas le créer et continuer, mais après la livraison de la correction, exécuter scripts/manuscript_state.py learn <dossier> <corrigé> pour enregistrer les décisions du jour (abréviations définies, orthographe majoritaire). Les nouvelles observations en conflit avec des valeurs existantes ne sont pas écrasées mais sont signalées à l'utilisateur.

Phase 2 : route_hint — 3 chemins d'intensité de correction

Parcourir le brouillon et décider entre light / standard / heavy, puis l'afficher. Pendant la correction, selon les règles de la Phase 3 ci-dessous, accumuler toujours le journal <corrigé>.edits.json section par section.

• light (1 passe) — Manuscrit déjà bien écrit (style niveau publication, seules quelques erreurs grammaticales éparses). Ne corriger que les violations des règles de base. Taux de modification minimal.
• standard (2 passes) — Cas général. Passe 1 : les 3 couches de règles de base (① anglais académique général — temps, articles, accord nombre ② uniformisation de l'orthographe des termes du domaine — Notation watch de la surcouche ③ registre de la revue). Passe 2 : auto-vérification + script de validation.
• heavy (3 passes et plus) — Nombreuses traductions littérales / signes IA, maladresses structurelles. Passe 1 : prétraitement spécifique au type (pitfalls ou ai-tell). Passe 2 : les 3 couches de règles de base. Passe 3 : lissage du flux des paragraphes et du développement. Puis validation.

Budget de correction (level) : route_hint est un diagnostic de l'état du manuscrit (ne pas modifier, décision de l'agent), tandis que level est le budget de modification choisi par l'utilisateur (par défaut : bas/low). Saisir via verify_integrity.py --level {low,mid,high} (enregistré dans log_edit.py --level) avec thresholds : low=bas/10-30%, mid=moyen/20-50%, high=haut/30-50% (ne peut pas être plus fort que la porte intégrée). Travail effectif = min(diagnostic, budget) — le budget peut réduire l'intensité requise par le diagnostic, mais jamais l'augmenter au-delà. Si le budget demandé et le diagnostic divergent, en informer explicitement l'utilisateur (ex. « Le manuscrit a reçu un diagnostic heavy, mais avec une demande bas, seules les violations des règles de base ont été corrigées »). Pour repartir sur le même manuscrit avec un objectif light, redemander.

Demande simultanée de plusieurs intensités : Si l'utilisateur demande « bas et moyen », « moyen et haut », ou « les trois », effectuer une correction, validation et livraison indépendantes pour chaque intensité. Les sorties sont nommées <manuscrit>.low.md / .mid.md / .high.md, et le journal (edits.json), le rapport (HTML) et le log (log_edit --level) sont également créés séparément pour chaque intensité.

Phase 3 : Correction par sections

Découper le manuscrit via scripts/section_split.py et l'identifier (IMRaD + Results and Discussion fusionnées, section Experimental etc.).

Obligation de rédiger le journal (edits.json) : Pendant la correction, accumuler au fur et à mesure <corrigé>.edits.json section par section — chaque édition n'est pas écrasée après suppression, mais on conserve les éléments kept (intervalles évalués mais non modifiés) avec leur raison. Le format suit le schéma v1 de scripts/check_journal.py :

• changed — édition où un intervalle du texte original (original) a été modifié en corrected (<40 tokens). Lier à la règle avec rule : {source, id} et enregistrer brièvement la raison dans reason.
• kept — intervalle évalué mais non touché. Enregistrer original (présent à l'identique dans les deux fichiers) et reason. rule est facultatif.

original et corrected doivent être des sous-chaînes exactes respectivement du texte original et du texte corrigé. Enregistrer même les modifications de ponctuation — la porte de couverture du journal vérifie mécaniquement que toutes les zones changed/insert/delete du diff sont couvertes par le journal. Les structures des conférences et des recueils varient, mais la macro-structure est un choix entre résumé/introduction/corps/résultats/conclusion ; les formats fusionnés (Results+Discussion, corps+résultats) ne sont pas des erreurs, ne pas les « normaliser » par correction. Les règles de temps, de voix passive, de développement et de souffle par section suivent references/core/academic-en.md §3 et §8.

• Methods = conserver la dominance du passé et du passif (ne pas forcer la voix active)
• Results = centré sur le passé, le présent pour les renvois aux figures. Ne pas mettre de phrases d'interprétation dans Results
• Discussion/Conclusion = interprétation au présent
• Abstract = forme abrégée de la section, appliquer les règles de mélange des temps
• Dans Introduction, ne pas créer de structure de conclusion (§8 vérification de contamination croisée) — ajouter des termes comme « in conclusion » dans l'introduction viole l'invariance sémantique

Demande de correction partielle (« seulement l'introduction », « seulement le corps »)

Si l'utilisateur ne demande qu'une section spécifique, verrouiller le périmètre : ne modifier que la section demandée, ne pas toucher aux autres. Maintenir le rôle de cette section (§8), n'appliquer aucune règle de section absente. Ne pas modifier les références croisées (« Section 3 », « Figure 4 ») ; signaler sous forme de note uniquement les références cassées. Exécuter la porte de validation également sur ce périmètre (academic-en.md §9).

Phase 4 : Validation (Portes de code — Pas d'auto-évaluation LLM)

Exécution des tests : même sur une console non UTF-8 (ex. Korean Windows cp949), la suite de tests spécifie explicitement l'encodage, donc l'exécuter sans variable d'environnement.

Avant livraison, exécuter impérativement les étapes suivantes et rapporter les résultats (Porte 0 d'abord, dans l'ordre — si une porte précédente renvoie exit 1, la livraison suivante est interdite) :

0. scripts/check_journal.py <original> <corrigé> --journal <corrigé>.edits.json — Porte de couverture du journal (toutes les zones modifiées du diff sont-elles couvertes par le journal, spans ≤40 tokens, rule.id existe-t-il dans rule.source). exit 1 bloque la livraison — ajouter les éditions/kept manquants ou découper les spans, puis réexécuter.

1. scripts/verify_integrity.py <original> <corrigé> --repeat 2 --report <corrigé>.integrity-report.html — Préservation des chiffres, unités, formules chimiques, citations, formules mathématiques, DOI (+ --overlay pour la terminologie spécialisée) + porte du taux de modification. exit 1 bloque la livraison — corriger les violations et réexécuter. Livrer le fichier de rapport (<corrigé>.integrity-report.html) avec la correction pour que l'utilisateur puisse examiner ce qui a changé via le diff.

2. scripts/check_terms.py <corrigé> — Cohérence de l'orthographe des termes (bandgap/band gap etc.). Si exit 1, unifier vers la forme majoritaire, puis réexécuter.

3. scripts/check_abbrev.py <corrigé> [--state <dossier>] — Détection des abréviations non définies. Si exit 1, ajouter la définition lors de la première occurrence, ou vérifier avec manuscript.json. Les abréviations non vérifiées (dont le développement est inconnu) sont enregistrées dans le registre via scripts/abbrev_registry.py references/abbrev-registry.json record <ABBR> --field <domaine> --context <phrase>. Par la suite, si le développement de la même abréviation est observé dans le même domaine (scan), il est mis à jour comme verified avec la phrase de contexte ; si un développement différent est observé, il est marqué comme conflict et demande confirmation à l'utilisateur. La vue pour humains est references/abbrev-registry.html (régénérée automatiquement, ne pas modifier ; SSOT = json).

4. Pour une correction partielle, exécuter les vérifications ci-dessus sur le périmètre concerné.

Lors de la livraison, exécuter scripts/log_edit.py <domaine> <route_hint> <A|B> <original> <corrigé> [--journal <corrigé>.edits.json] pour enregistrer la paire de correction et (si inséré) le journal dans logs/edits/ (mesure du bench qualité, pipeline pitfalls, pourquoi a-t-on modifié).

Mesure de qualité (pour l'amélioration de la compétence elle-même)

scripts/bench_edit.py <original> <corrigé> — Compare les violations/100 mots (AI-tell, hedging redondant, modificateurs exagérés, temps des figures, phrases longues, densité excessive d'adverbes de transition, incohérence de notation) avant et après correction. Ce n'est pas une porte de livraison mais un dispositif de mesure de performance de la compétence : lors des cycles de delta mensuels/bimensuels, appliquer aux cas golden et aux logs de correction réels ; si le taux de violation régresse (exit 1), revenir sur les modifications de surcouche/règle.

Fichiers de référence

• references/core/academic-en.md — Temps, articles, équilibre passif, adverbes de transition, hedging (commun à tous les domaines)
• references/core/ai-tell-en.md — Patrons de détection de brouillon IA en anglais (incluant preuves de non-occurrence dans les revues)
• references/core/korean-author-pitfalls.md — Dictionnaire des erreurs des locuteurs coréens (première édition, croît par accumulation de diff)
• references/overlays/<domaine>.md — Mesures empiriques par domaine : indicateurs de style, termes principaux, phrase bank, liste de surveillance des notations. Généré automatiquement par scripts/mine_corpus.py depuis ~/Documents/papers/<domaine>/, mis à jour deux fois par semaine.

Ce qui n'est pas fait

• Ajouter, supprimer ou restructurer le contenu (violation de l'invariance sémantique)
• Appliquer des règles de simplification non académiques comme ASD-STE100, Plain English
• Rejeter la question ouverte à l'utilisateur sans connaître le domaine
• Fournir un rapport « vérifié » sans script de validation