nomoredasi — Correção Acadêmica de Inglês Sensível à Área (v0.1)

O que nomoredasi — Correção Acadêmica de Inglês Sensível à Área (v0.1) faz?

Um skill para refinar o manuscrito antes que alguém peça "refaça isso". Corrige o texto para o nível de inglês exigido por periódicos da família Nature. As convenções específicas de área (escolha lexical, densidade, ritmo, estrutura de desenvolvimento) são tratadas por references/overlays/<area>.md, e as regras comuns a todas as áreas por references/core/.

4 Princípios Fundamentais (comuns a todos os caminhos; violação implica não entrega)

1. Invariância de significado — Não alterar conteúdo, argumentação ou ordem lógica. Apenas estilo e expressão.
2. Baseado em evidências — Toda correção deve ser fundamentada nas regras de references/core/ ou nas medições de corpus do overlay da área correspondente. Não remover expressões "parecidas com IA" por intuição.
3. Manutenção do gênero — Preservar o registro acadêmico. Proibido coloquializar ou ensaísticar. Proibido aplicar regras do estilo ASD-STE100 (voz ativa forçada, limite de 20 palavras por frase, proibição de -ing) — entram em conflito com as medições dos periódicos reais (voz passiva 111–137/10K, média de 16,5–18,3 palavras por frase; ver references/core/academic-en.md).
4. Proibição de revisão excessiva — Aviso se a taxa de alteração ultrapassar 30%; interromper e solicitar confirmação do usuário se ultrapassar 50%. O script scripts/verify_integrity.py faz a verificação definitiva.

Fase 0: Identificação do Tipo de Entrada

No início do trabalho, imprimir uma linha. O rótulo segue o idioma da solicitação do usuário:

• Solicitação em coreano: nomoredasi v0.1 — tipo {A|B} / área: {área definida}

• Solicitação em inglês: nomoredasi v0.1 — type {A|B} / field: {resolved field}

• Outros idiomas: traduzir os rótulos type/field para o idioma correspondente.

• Tipo A (manuscrito original em coreano) — Caminho combinado de tradução + correção. Primeiro detectar estruturas de viés de tradução em references/core/korean-author-pitfalls.md (como "através de", "por meio de") para bloquear traduções literais; depois aplicar as mesmas 3 camadas de regras do Tipo B.

• Tipo B (manuscrito em inglês, incluindo rascunhos de IA) — Caminho de correção. Se houver sinais de rascunho de IA, aplicar adicionalmente a camada references/core/ai-tell-en.md.

Fase 1: Roteamento por Área (Prioridade em 3 Etapas)

1. Declaração do usuário — Se o usuário especificar a área, usar essa.
2. Caminho do arquivo — Se o manuscrito estiver em uma pasta como papers/<area>/, usar o nome da pasta.
3. Detecção automática — Executar scripts/route_field.py <manuscrito>, usar o resultado de maior pontuação. Se os dois primeiros resultados tiverem pontuações próximas, mesclar os dois overlays.
4. Se incerto, confirmar uma vez — Não fazer perguntas abertas. Apresentar uma estimativa no formato "Parece ser Optics and Photonics. Se concordar, prossigo" e perguntar apenas uma vez.

As regras centrais funcionam independentemente da área, portanto mesmo que a área esteja errada é seguro. Se não houver overlay para a área, prosseguir apenas com as regras centrais e informar esse fato. Se o cabeçalho do overlay indicar Maturity: como immature (menos de 10 artigos ou menos de 100K palavras), os valores numéricos devem ser tratados como referências direcionais, não como alvos rígidos.

Fase 1.5: Arquivo de Estado do Manuscrito (manuscript.json)

Se a pasta do manuscrito contiver manuscript.json, lê-lo e incorporar seu conteúdo — lista de abreviações definidas, grafia consolidada de termos (ex.: bandgap), lista de figuras. É um mecanismo para manter consistência em todo o documento durante revisões parciais ou repetidas. Se não existir, não criar um novo, mas após a entrega da correção, executar scripts/manuscript_state.py learn <pasta> <versao_corrigida> para registrar as decisões do dia (abreviações definidas, grafias predominantes). Novas observações conflitantes com valores existentes não sobrescrevem; são relatadas ao usuário.

Fase 2: route_hint — 3 Caminhos de Intensidade de Correção

Analisar o rascunho e decidir entre light / standard / heavy, imprimindo o resultado. Durante a correção, sempre acumular o diário <versao_corrigida>.edits.json por seção, de acordo com as regras da Fase 3 abaixo.

• light (1 passada) — Manuscrito já bem escrito (estilo aceitável para publicação, apenas erros gramaticais esporádicos). Corrigir apenas violações das regras centrais e encerrar. Taxa de alteração mínima.
• standard (2 passadas) — Caso geral. Passada 1: 3 camadas de regras centrais (① Inglês acadêmico geral — tempo verbal, artigos, concordância; ② Uniformização de terminologia da área — Notação watch do overlay; ③ Registro do periódico). Passada 2: Auto-revisão + script de verificação.
• heavy (3+ passadas) — Muitos vícios de tradução/sinais de IA, estranhezas estruturais. Passada 1: Pré-processamento específico do tipo (pitfalls ou ai-tell). Passada 2: 3 camadas de regras centrais. Passada 3: Ajuste de fluxo e desenvolvimento de parágrafos. Depois, verificação.

Eixo de orçamento de intensidade de correção (level): o route_hint é um diagnóstico do estado do manuscrito (não deve ser alterado; julgamento do agente); o level é o orçamento de alterações escolhido pelo usuário (padrão baixo/low). É definido com verify_integrity.py --level {low,mid,high} (registrado por log_edit.py --level), aplicando limites: low=baixo 10-30%, mid=médio 20-50%, high=alto 30-50% (não pode ser mais forte que os gates embutidos). Trabalho efetivo = min(diagnóstico, orçamento) — o orçamento pode diminuir a intensidade exigida pelo diagnóstico, mas nunca aumentá-la. Se houver divergência entre orçamento solicitado e diagnóstico, informar explicitamente o usuário (ex.: "Manuscrito com diagnóstico heavy, mas orçamento baixo; corrigi apenas violações das regras centrais"). Para saltar com o mesmo manuscrito para o objetivo light, o usuário deve fazer nova solicitação.

Solicitação de múltiplas intensidades simultâneas: Se o usuário solicitar várias intensidades ("baixo e médio", "médio e alto", "todos os três"), realizar correção, verificação e entrega independentes para cada intensidade. A saída é separada em <nome_manuscrito>.low.md / .mid.md / .high.md, e o diário (edits.json), relatório (HTML) e log (log_edit --level) são gerados para cada intensidade.

Fase 3: Correção com Reconhecimento de Seções

Dividir o manuscrito com scripts/section_split.py para reconhecimento (IMRaD + Results and Discussion fusão, Experimental Section etc., com variações).

Obrigação de criar o diário (edits.json): Durante a correção, acumular gradualmente <versao_corrigida>.edits.json por seção — cada edição não é preenchida posteriormente; pelo contrário, registra-se também itens kept (trechos avaliados mas não alterados). O formato segue o schema v1 de scripts/check_journal.py:

• changed — Edições que alteram um trecho original (original, corrected na versão corrigida, <40 tokens). Apontar a regra de fundamentação com rule: {source, id} e registrar breve motivo em reason.
• kept — Trechos avaliados mas não tocados. Registrar original (presente em ambos os arquivos) e reason. rule é opcional.

original e corrected devem ser substrings exatas do manuscrito original e da versão corrigida, respectivamente. Não omitir edições de pontuação — o gate de cobertura do diário verifica mecanicamente se todas as áreas changed/insert/delete do diff foram cobertas pelo diário. As estruturas de seções variam entre conferências e periódicos, mas a macroestrutura é uma escolha entre resumo/introdução/corpo/resultados/conclusão; fusões (Results+Discussion, corpo+resultados) não são erros e não devem ser "normalizadas" pela correção. Regras de tempo verbal, voz passiva, desenvolvimento e ritmo por seção seguem references/core/academic-en.md §3 e §8.

• Methods = manter passado/voz passiva predominantes (proibido forçar voz ativa)
• Results = foco no passado, presente para indicação de figuras. Não inserir frases interpretativas em Results
• Discussion/Conclusion = interpretação no presente
• Abstract = versão reduzida das seções, com regras de mistura de tempos verbais
• Introduction não deve conter estrutura de conclusão (§8 verificação de contaminação cruzada) — adicionar expressões como "in conclusion" na introdução viola a invariância de significado

Solicitação de Revisão Parcial ("apenas introdução", "apenas corpo")

Se o usuário solicitar apenas uma seção específica, travar o escopo: corrigir apenas o trecho solicitado; não tocar nas outras seções. Manter o papel daquela seção (§8), não aplicar regras de seções ausentes, não editar referências cruzadas ("Seção 3", "Figura 4") exceto para relatar como nota referências quebradas. O gate de verificação também é executado apenas sobre aquele trecho (academic-en.md §9).

Fase 4: Verificação (Gates de Código — Proibido Autojulgamento por LLM)

Executar testes: mesmo em consoles não UTF-8 (ex.: Korean Windows cp949) o conjunto de testes especifica codificação explicitamente; executar sem variáveis de ambiente.

Antes da entrega, executar obrigatoriamente os passos abaixo e relatar os resultados (gate 0 em diante, sequencialmente — se um gate anterior terminar com exit 1, bloquear entregas subsequentes):

0. scripts/check_journal.py <original> <corrigido> --journal <corrigido>.edits.json — Gate de cobertura do diário (todas as áreas de alteração do diff estão cobertas pelo diário, spans ≤40 tokens, rule.id existe em rule.source). Se exit 1, bloquear entrega — complementar o diário com edições/kept faltantes ou dividir spans e reexecutar.

1. scripts/verify_integrity.py <original> <corrigido> --repeat 2 --report <corrigido>.integrity-report.html — Preservação de números, unidades, fórmulas químicas, citações, equações, DOI (＋ --overlay para terminologia especializada) + gate de taxa de alteração. Se exit 1, bloquear entrega; corrigir as violações e reexecutar. Entregar o arquivo de relatório (<corrigido>.integrity-report.html) junto com a versão corrigida para que o usuário possa revisar as alterações via diff.

2. scripts/check_terms.py <corrigido> — Consistência de grafia de termos (bandgap/band gap, etc.). Se exit 1, unificar pela forma predominante e reexecutar.

3. scripts/check_abbrev.py <corrigido> [--state <pasta>] — Detecção de abreviações não definidas. Se exit 1, adicionar definição na primeira ocorrência ou confrontar com manuscript.json. Abreviações não verificadas (cuja expansão é desconhecida) são registradas no registro com scripts/abbrev_registry.py references/abbrev-registry.json record <ABBR> --field <area> --context <frase>. Posteriormente, se a mesma abreviatura for observada com a mesma expansão em textos da mesma área (scan), é atualizada como verified com a frase de contexto; se for observada com expansão diferente, marcada como conflict — conflitos requerem confirmação do usuário. A visualização para humanos está em references/abbrev-registry.html (regenerado automaticamente, não editar; SSOT é o json).

4. Se for revisão parcial, executar as verificações acima apenas sobre o trecho correspondente.

Na entrega, executar scripts/log_edit.py <area> <route_hint> <A|B> <original> <corrigido> [--journal <corrigido>.edits.json] para registrar o par de correção e (se houver) o diário em logs/edits/ (para medição de benchmark de qualidade, pipeline de pitfalls, e entrada do diário de por que foi alterado).

Medição de Qualidade (para aprimoramento do próprio skill)

scripts/bench_edit.py <original> <corrigido> — Compara violações/100 palavras (AI-tell, hedge aninhado, modificadores excessivos, tempo verbal de figuras, frases longas, densidade de advérbios de transição, inconsistência de notação) antes e depois da correção. Não é um gate de entrega, mas um dispositivo de medição de desempenho do skill: nos ciclos delta mensais/quinzenais, aplicar a casos golden e logs de correção reais; se a taxa de violações regredir (exit 1), reverter as alterações de overlay/regras.

Arquivos de Referência

• references/core/academic-en.md — Tempo verbal, artigos, equilíbrio de voz passiva, advérbios de transição, hedges (comuns a todas as áreas)
• references/core/ai-tell-en.md — Padrões de detecção de rascunhos de IA em inglês (inclui fundamentos de não ocorrência em periódicos)
• references/core/korean-author-pitfalls.md — Dicionário de erros de falantes de coreano (primeira edição, cresce por acúmulo de diffs)
• references/overlays/<area>.md — Medições por área: indicadores de estilo, termos principais, banco de frases, lista de vigilância de notação. Gerado automaticamente por scripts/mine_corpus.py a partir de ~/Documents/papers/<area>/, atualizado duas vezes por semana.

O que não fazer

• Adicionar, remover ou reestruturar conteúdo (viola invariância de significado)
• Aplicar regras de simplificação não acadêmicas como ASD-STE100, Plain English, etc.
• Repassar para o usuário com perguntas abertas sem saber a área
• Relatar apenas "verifiquei" sem executar scripts de verificação