Odporność generatora digestów: fallbacki Gemini, bramki walidacji i CI

Co zrobiłem

• Wielomodelowe fallbacki Gemini i ograniczenia czasowe: Zbudowałem mechanizm awaryjny dla modeli Gemini oraz ustawiłem 90s timeout na odpowiedzi.
• Smart number gate i detekcja dostawcy: Wdrożyłem bramkę weryfikującą liczby (smart number gate) oraz automatyczne wykrywanie providera na bazie obecności GEMINI_API_KEY.
• Kolejność wykonywania bramek w CI: Zoptymalizowałem potok w CI tak, aby deterministyczne bramki uruchamiały się przed kosztownym krokem przeglądu (paid review pass).
• Skrypty i weryfikacja i18n: Dodałem skrypt check:i18n do pliku package.json i włączyłem go do sprawdzianów w CI.
• Konfiguracja środowiska CI i audyt: Ustawiłem tożsamość autora git w CI runnerze oraz w gitFlow, a także przeprowadziłem rutynowy audyt (daily self-check 2026-08-26).

Dlaczego to ważne

• Odporność na awarie zewnętrzne: Wielomodelowy fallback oraz 90s timeout zabezpieczają proces przed przestojami w przypadku niedostępności lub opóźnień konkretnego wariantu Gemini.
• Redukcja kosztów API: Uruchamianie deterministycznych bramek przed płatnymi zapytaniami odrzuca błędne przetwarzanie na wczesnym etapie, eliminując niepotrzebne zużycie tokenów.
• Poprawa stabilności CI: Wykrywanie zmiennej GEMINI_API_KEY, dedykowany skrypt check:i18n w package.json oraz jawna konfiguracja tożsamości w gitFlow usuwają ryzyko błędów budowania w środowisku CI.

Czego się nauczyłem

• Deterministyczna walidacja przed kosztownymi wywołaniami: Uruchomienie tanich bramek sprawdzających przed płatnym przebiegiem LLM chroni budżet projektu.
• Fallback musi być wielomodelowy: Poleganie na jednym punkcie końcowym API tworzy wąskie gardło; automatyczna zmiana wariantu modelu uniezależnia potok od opóźnień dostawcy.