fix: restaura a chave "text" em Abstract.data

[Rossi-Luciano]

O que esse PR faz?

Restaura a chave "text" em Abstract.data (packtools/sps/models/v2/abstract.py), removida sem intenção pelo PR #1064.

Histórico do problema:

• O PR Adicionar chave text em Abstract.data #1072 (commit bb3f0a2, 27/01/2026) adicionou a property text e a chave "text" em Abstract.data, com testes cobrindo resumo estruturado (<sec>) e simples (<p>).
• 16 dias depois, o PR Implementa validação completa de abstracts conforme SPS 1.10 #1064 (commit 3827104, 12/02/2026, "Implementa validação completa de abstracts conforme SPS 1.10") substituiu a linha "text": self.text, por graphic_href/fig_id/caption ao adicionar suporte a Visual Abstract — sem perceber que isso derrubava o fix anterior. A property text em si nunca foi removida, só ficou órfã, sem ser incluída no dict retornado por data.
• Consequência: os 3 testes adicionados pelo PR Adicionar chave text em Abstract.data #1072 para essa chave (test_data_contains_text_key, test_data_text_value_with_sections, test_data_text_value_without_sections) ficaram falhando em master desde então, sem bloquear merges subsequentes. Isso também zerou o texto do resumo de qualquer artigo processado com packtools ≥ 4.15.0 para consumidores externos como o scms-upload (ver [Migração de Artigos XMLs] Casos onde o texto do resumo não aparecem scms-upload#1031).

Este PR restaura só a linha "text": self.text,, mantendo os campos de Visual Abstract adicionados pelo #1064.

Onde a revisão poderia começar?

packtools/sps/models/v2/abstract.py, property data da classe Abstract (linha ~277).

Como este poderia ser testado manualmente?

pytest tests/sps/models/v2/test_abstract.py -v

Os 3 testes que estavam falhando (test_data_contains_text_key, test_data_text_value_with_sections, test_data_text_value_without_sections) voltam a passar. Também rodei toda tests/sps/models/v2/ (exceto test_notes.py, que já falha na coleta em master por um ModuleNotFoundError não relacionado a este PR) e tests/sps/validation/test_article_abstract.py: 71 passed, 1 skipped, sem regressões.

Algum cenário de contexto que queira dar?

Esse "vaivém" (adicionado em #1072, removido em #1064) provavelmente aconteceu porque a branch do #1064 foi criada antes do #1072 ser mesclado e não foi rebaseada antes do merge — o diff substituiu a linha original sem considerar que ela já tinha sido reintroduzida por outro PR nesse meio-tempo.

O impacto em produção: qualquer artigo publicado via scms-upload com packtools ≥ 4.15.0 (produção roda 4.16.4) desde 12/02/2026 teve o campo abstract/abstracts do payload de publicação vazio, mesmo com o XML contendo o resumo corretamente estruturado em <p>/<sec>. Já existe um fix defensivo do lado scms-upload (scieloorg/scms-upload#1034) com um fallback que recompõe o texto a partir de p/sections quando a chave text está ausente — mas a causa raiz é esta, e vale corrigir aqui para beneficiar outros consumidores do packtools também.

Screenshots

Não aplicável (correção de modelo de dados, sem interface).

Quais são os tickets relevantes?

• Relacionado a [Migração de Artigos XMLs] Casos onde o texto do resumo não aparecem scms-upload#1031
• Corrige a regressão introduzida em Implementa validação completa de abstracts conforme SPS 1.10 #1064
• Restaura o que Adicionar chave text em Abstract.data #1072 já tinha corrigido

Referências

• Adicionar chave text em Abstract.data #1072 — PR que originalmente adicionou a chave text
• Implementa validação completa de abstracts conforme SPS 1.10 #1064 — PR que a removeu sem intenção

---

Segurança da informação (NSI.04)

Este PR manipula dados sensíveis ou pessoais (LGPD)?

• Não

Este PR altera autenticação, autorização, controle de acesso ou gerenciamento de sessão?

• Não

Este PR introduz, atualiza ou remove dependências de terceiros?

• Não

Este PR foi validado pelo pipeline de segurança (SonarQube / Trivy)?

• Não aplicável a este PR — mudança de uma linha em um dict já existente, sem nova superfície de ataque

Este PR concatena, monta ou executa comandos SQL, HTML ou JavaScript a partir de entrada externa?

• Não

Este PR expõe novos endpoints, telas ou serviços?

• Não

Algum segredo, senha, chave ou token está sendo adicionado ao código-fonte?

• Não, nenhum segredo foi commitado