Implementar validações para elemento <history> conforme SPS 1.10

[Copilot]

O que esse PR faz?

Implementa validações estruturais para o elemento <history> conforme especificação SPS 1.10, alcançando 83% de conformidade (10 de 12 regras), superando a meta de 75%.

Regras implementadas:

• P0 (Críticas - 7/7): unicidade, presença de @date-type, valores permitidos, datas obrigatórias (received/accepted), completude de datas críticas, presença de ano
• P1 (Importantes - 3/3): delegadas para validadores existentes em dates.py (formato dia/mês, validação de data)
• P2 (Futuras - 0/2): ordem cronológica e validação cruzada reviewer-report (fora do escopo)

Tipos de artigo isentos reconhecidos: correction, retraction, addendum, expression-of-concern, reviewer-report

Onde a revisão poderia começar?

1. packtools/sps/validation/history.py - Lógica de validação (384 linhas)
2. tests/sps/validation/test_history.py - Cobertura de testes (30 casos, 100% aprovados)

Como este poderia ser testado manualmente?

from lxml import etree
from packtools.sps.validation.history import HistoryValidation

xml = """
<article article-type="research-article">
    <front>
        <article-meta>
            <history>
                <date date-type="received">
                    <day>15</day>
                    <month>03</month>
                    <year>2024</year>
                </date>
                <date date-type="accepted">
                    <day>12</day>
                    <month>05</month>
                    <year>2024</year>
                </date>
            </history>
        </article-meta>
    </front>
</article>
"""

tree = etree.fromstring(xml)
validator = HistoryValidation(tree)
results = list(validator.validate())

# Verificar erros
errors = [r for r in results if r['response'] != 'OK']
print(f"Total: {len(results)}, Erros: {len(errors)}")

Casos de teste:

• XML válido → errors vazio
• XML sem @date-type → erro CRITICAL
• XML sem received/accepted → erro CRITICAL (exceto tipos isentos)
• XML com múltiplos <history> → erro ERROR

Algum cenário de contexto que queira dar?

Decisões de design:

• Separação de responsabilidades: validação estrutural (history.py) vs. validação de formato (dates.py)
• Evita duplicação de código reutilizando build_response() e validadores de formato existentes
• Design extensível permite adição futura de regras P2

Testes e segurança:

• 30 testes aprovados (100%)
• Testes de modelos de data: 42/42 aprovados
• CodeQL: 0 vulnerabilidades
• Sem regressões em testes existentes

Valores permitidos para @date-type:
received, accepted, corrected, expression-of-concern, pub, preprint, resubmitted, retracted, rev-recd, rev-request, reviewer-report-received

Screenshots

N/A

Referências

• Especificação SPS 1.10 - Elemento history
• Implementação de referência: packtools/sps/validation/article_doi.py

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Criar validações para o elemento </issue_title>
<issue_description>## Objetivo

Implementar validações para o elemento <history> conforme a especificação SPS 1.10, aumentando a conformidade de X% para 75% (9 de 12 regras).

Nota: Algumas validações para <history> podem já estar parcialmente implementadas no repositório. Este Issue visa reavaliar, complementar e garantir cobertura completa das regras SPS 1.10.

---

Contexto

O elemento <history> agrupa as datas de histórico do documento (recebido, aceito, revisado, preprint, correções, retratações, etc.). Validações corretas garantem que datas obrigatórias estejam presentes, que formatos sejam consistentes (dois dígitos para dia/mês), e que apenas valores permitidos sejam usados para @date-type.

Conformidade atual: X de 12 regras implementadas (X%)
Meta após implementação: 9 de 12 regras (75%)

---

Documentação SPS

Referência oficial: https://docs.google.com/document/d/1GTv4Inc2LS_AXY-ToHT3HmO66UT0VAHWJNOIqzBNSgA/edit?tab=t.0#heading=h.history

Regras principais conforme SPS 1.10:

1. Ocorrência:

   • <history> deve aparecer no máximo uma vez em <article-meta> ou <front-stub>

2. Datas obrigatórias:

   • <date date-type="received"> é obrigatório (exceto para errata, retratação, adendo, manifestação de preocupação e parecer)
   • <date date-type="accepted"> é obrigatório (exceto para errata, retratação, adendo, manifestação de preocupação e parecer)

3. Valores permitidos para @date-type:

   • received - Data de recebimento do manuscrito
   • accepted - Data de aceitação do manuscrito
   • corrected - Data de aprovação de Errata ou Adendo
   • expression-of-concern - Data de aprovação de Manifestação de Preocupação
   • pub - Data de publicação
   • preprint - Data de publicação como preprint
   • resubmitted - Data de reenvio do manuscrito
   • retracted - Data de aprovação de retratação
   • rev-recd - Data de recebimento do manuscrito revisado
   • rev-request - Data de solicitação de revisões
   • reviewer-report-received - Data de envio de parecer (exclusivo para @article-type="reviewer-report")

4. Elementos obrigatórios por tipo de data:

   • Para received, accepted, corrected, retracted, expression-of-concern: <day>, <month> e <year> são obrigatórios
   • Para todos os outros tipos: pelo menos <year> é obrigatório

5. Formato obrigatório:

   • <day> deve ter dois dígitos: 01, 02, ..., 31
   • <month> deve ter dois dígitos: 01, 02, ..., 12

6. Validação de data:

   • Valores de <day>, <month> e <year> devem formar uma data válida

---

Regras a Implementar

P0 – Críticas (implementar obrigatoriamente)

#	Regra	Nível	Descrição
1	Validar unicidade de <history>	ERROR	O elemento <history> deve aparecer no máximo uma vez em <article-meta> ou <front-stub>
2	Validar presença de @date-type em <date>	CRITICAL	O atributo @date-type é obrigatório em todos os <date> dentro de <history>
3	Validar valores permitidos de @date-type	ERROR	O valor de @date-type deve estar na lista de valores permitidos
4	Validar presença de <date date-type="received">	CRITICAL	A data com @date-type="received" é obrigatória (exceto para errata, retratação, adendo, manifestação de preocupação e parecer)
5	Validar presença de <date date-type="accepted">	CRITICAL	A data com @date-type="accepted" é obrigatória (exceto para errata, retratação, adendo, manifestação de preocupação e parecer)
6	Validar completude de data para tipos críticos	CRITICAL	Para received, accepted, corrected, retracted, expression-of-concern: <day>, <month> e <year> são obrigatórios
7	Validar presença mínima de <year>	CRITICAL	Para todos os tipos de data, pelo menos <year> deve estar presente

P1 – Importantes (implementar se possível)

#	Regra	Nível	Descrição
8	Validar formato de <day> (dois dígitos)	ERROR	O elemento <day> deve ter exatamente dois dígitos (01-31)
9	Validar formato de <month> (dois dígitos)	ERROR	O elemento <month> deve ter exatamente dois dígitos (01-12)
10	Validar data válida	ERROR	Valores de <day>, <month> e <year> devem formar uma data válida (ex: 31/02 é inválido)

P2 – Futuras (fora do escopo deste Issue)

#	Regra	Motivo de exclusão
11	Validar ordem cronológica de datas (received < accepted < pub)	Média complexidade - requer lógica de comparação de datas e decisão sobre quais datas comparar
12	Validar uso correto de reviewer-report-received com @article-type="reviewer-report"	Baixa prioridade - requer validação cruzada c...

• Fixes Criar validações para o elemento <history> #1087

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.