[Gabrymi93]

Sintesi

Il merge editoriale del registry builder sovrascriveva sempre il period derivato dal time_coverage del dataset.yml con il valore storico del registry esistente: un cambio di copertura temporale nei config non propagava mai al registry.

Contesto collegato

Regression visto in dataciviclab/energia-italia#6 (espansione serie Terna 2015→2000/2005): il registry continuava a dichiarare 2015-2024 nonostante i config e i dati aggiornati. Lo schema documenta che period viene "da time_coverage del dataset.yml" — il comportamento contraddiceva il contratto.

Cosa cambia

• Bug fix
• Nuova funzionalità del motore
• Nuovo plugin sorgente
• Modifica contratto pubblico
• Refactor / performance
• Documentazione
• Dipendenze o CI

builders.py: l'editoriale copre ora solo l'assenza di time_coverage nel config; se il config dichiara time_coverage, il valore derivato vince.

Verifica

pytest tests/test_registry_builder.py -q   # 31 passed (2 nuovi policy)
ruff check + mypy sui file toccati

• test_period_time_coverage_beats_editorial — fallisce senza il fix (verificato), passa con il fix
• test_period_editorial_fills_when_no_time_coverage — l'editoriale resta la fonte senza time_coverage

Note per chi revisiona

• Comportamento invariato per i dataset senza time_coverage: l'editoriale fa ancora da fonte (compatibilità piena).
• Per propagare il fix ai registry già commitati serve un rebuild (toolkit registry build --write) nei repo interessati dopo il merge/release.

Metriche PR

Tipo: root fix (contract alignment con registry.schema.json)
Problema reale: merge editoriale sovrascrive period da time_coverage con valore storico
Contratto allineato: registry.schema.json — "period ... da time_coverage del dataset.yml"
Test aggiunti: 2 policy (1 regression reale, 1 comportamento preservato)
Rischio residuo: nessuno — i dataset senza time_coverage non cambiano
Follow-up: rebuild registry nei repo che hanno cambiato time_coverage