Odporność generatora digestów: multi-model fallback dla Gemini i domknięcie walidacji w CI

Co zrobiłem

• Zbudowałem mechanizm multi-model fallback dla Gemini w module digest, wraz z automatyczną detekcją providera przy użyciu GEMINI_API_KEY oraz twardym timeoutem 90 sekund na zapytania.
• Udoskonaliłem mechanizm weryfikacji faktów (smart number gate): dodałem zmienną windowHours do zbioru zaakceptowanych liczb (grounded numbers set), zapobiegając fałszywym alarmom o halucynacjach.
• Zoptymalizowałem konfigurację CI/CD:
  • Ograniczyłem wyzwalanie zdarzenia pull_request wyłącznie do gałęzi main.
  • Dodałem skrypt check:i18n do package.json oraz podpiąłem go pod krok weryfikacyjny w CI.
  • Skonfigurowałem tożsamość autora gita (git author identity) bezpośrednio w runnerze CI oraz w logice gitFlow.
• Przeprowadziłem rutynowy audyt dzienny repozytorium (daily self-check).

Dlaczego toważne

• Niezawodność integracji z LLM: Zewnętrzne API modeli językowych bywają niestabilne. Dodanie stratygii multi-model fallback dla Gemini w połączeniu z 90-sekundowym limitem czasu oznacza, że chwilowy przestój jednego modelu lub opóźnienie w sieci nie uderzają w ciągłość działania systemu.
• Ochrona przed halucynacjami bez fałszywych alarmów: Ograniczenie liczb wyłącznie do tych obecnych w danych wejściowych chroni przed zmyślonymi statystykami. Dodanie zmiennej windowHours do zbiory liczb uzasadnionych (grounded) zapobiega sytuacji, w której poprawne ramy czasowe analizy są odrzucane jako błąd.
• Krótszy czas i czystość buildów: Zawężenie triggerów PR ogranicza niepotrzebne uruchomienia pipeline'ów w GitHub Actions. Wdrożenie testu check:i18n w CI wychwytuje braki w tłumaczeniach przed połączeniem kodu do main.

Czego się nauczyłem

• Asercja danych liczbowych wymaga ścisłego kontekstu operacyjnego. Jeśli walidujesz tekst z LLM pod kątem halucynacji cyfr, zestaw liczb dozwolonych musi zawierać nie tylko surowe dane, ale też parametry wykonawcze (takie jak okno czasowe windowHours).
• Resilience w systemach z agentami AI to warstwy, nie pojedynczy mechanizm. Twardy timeout (90s), płynny fallback między wariantami modeli oraz automatyczna detekcja kluczy API muszą działać wspólnie, by pipeline był w pełni bezobsługowy.