Codex/fix bling response validation

[tempont]

No description provided.

[tempont-bot]

Mira PR Walkthrough

This PR fixes response validation in the generated Bling ERP API models. It introduces a new/adjusted custom field type in fields.py and updates the model generator (generate_models.py) so that regenerated schemas (notably the logistics logistics/remessas/objetos response schemas) validate API responses correctly, likely tolerating real-world response shapes that previously failed strict validation. The bulk of the diff is a mechanical regeneration sweep across all generated schema modules, plus documentation and changelog updates describing the fix.

Confidence: 4/5   ◉◉◉◉○   Safe to merge

• Changes are mostly generated-schema regeneration plus a small, contained fix in fields.py and the model generator; the affected surface (logistics response validation) is narrow, though the lack of visible test changes warrants a quick check that existing tests cover the new field behavior.

Key files to review:

• src/bling_erp_api/models/fields.py:78 — The new BlingDatetime validator pipeline (sentinel normalization, America/Sao_Paulo localization, DST handling, JSON serialization) ships with no tests; a regression would silently mis-parse every tracking timestamp.
• src/bling_erp_api/models/fields.py:74 — Naive timestamps inside the repeated hour at a historical DST-end transition resolve to the DST offset (fold=0 default), which may misinterpret Bling's stored time by one hour; the choice is undocumented and untested.

50 files reviewed · 2 comments (⚠️ 1 warning, 💡 1 suggestion)

---

Comment @tempont-bot help to get the list of available commands and usage tips.

[tempont-bot]

Mira Review Summary

The new BlingDatetime validator pipeline in src/bling_erp_api/models/fields.py ships without any test coverage, meaning a regression in the sentinel normalization, America/Sao_Paulo localization, DST handling, or JSON serialization would silently mis-parse timestamps. Separately, naive timestamps falling in the repeated hour of a historical DST-end transition silently resolve to the DST offset (fold=0 default), which may misinterpret Bling's stored time by one hour, and this resolution choice is currently undocumented.

Key Issues

	Issue	Location
🔴	The new BlingDatetime validator pipeline (sentinel normalization, America/Sao_Paulo localization, DST handling, JSON serialization) ships with no tests; a regression would silently mis-parse every tracking timestamp.	src/bling_erp_api/models/fields.py:78
🔴	Naive timestamps inside the repeated hour at a historical DST-end transition resolve to the DST offset (fold=0 default), which may misinterpret Bling's stored time by one hour; the choice is undocumented and untested.	src/bling_erp_api/models/fields.py:74