grantforge-api / implementation_plan.md
GrantForge Bot
Deploy to Hugging Face
afd56bc

Stabilizacja CI/CD i Autofix - GrantForge AI

Zaproponowane przez Ciebie zalecenia to doskonały plan ratunkowy (tzw. "firefighting plan"), aby przywrócić stabilność w procesie wytwarzania oprogramowania oraz ulepszyć najbardziej awaryjny punkt systemu — Autofix.

Proposed Changes

Poniżej znajduje się szczegółowy plan implementacji Kroków 1 i 2, od razu w tej iteracji.


1. Pre-commit Hooks & Local Checks

Wprowadzimy blokadę błędnych pushy poprzez narzędzie pre-commit. Pozwoli to na lokalne wyłapywanie błędów lintingu i testów przed wypchnięciem kodu na serwer.

[NEW] .pre-commit-config.yaml

  • Konfiguracja hooków do ruff (linter i formatter) oraz pytest (uruchomienie szybkich testów backendowych przed pushem).
  • Dodanie instrukcji w README, jak wykonać pip install pre-commit && pre-commit install -t pre-push.

[NEW] scripts/pre_push_tests.sh

  • Prosty skrypt bashowy odpalany przez pre-commit (hook typu pre-push), który uruchomi pytest tests/ wewnątrz katalogu backend. W razie błędu — git push zostanie zablokowany.

2. Autofix Resilience: Backoff, Retry & Fuzzy Matching

Obecnie funkcja autofix przekazuje wszystkie błędy audytu do modelu przy poprawianiu każdej sekcji osobno, co wywołuje halucynacje LLM. Co więcej, wywołania z Frontendu padają z błędem 429 (Rate Limit).

[MODIFY] backend/endpoints/projects.py

  • Fuzzy Matching Issues: Dodanie logiki filtrowania audit_data["issues"]. Zamiast przesyłać wszystkie błędy, użyjemy SequenceMatcher z biblioteki difflib, aby dopasować issue['affected_section'] do section_t (z progiem podobieństwa np. 0.6) oraz dołączyć błędy oznaczone jako "Ogólne". To znacznie poprawi kontekst dla LLM.
  • Backend Retries: Dodanie .with_retry(stop_after_attempt=3, wait_exponential_jitter=True) (lub wbudowanego w klasę modelu max_retries) na poziomie łańcucha Langchain (chain.invoke), co ukryje błędy 429 z API Google.

[MODIFY] frontend-react/src/components/project/ProjectAuditPanel.tsx

  • Frontend Retry & Backoff Loop: Ulepszenie pętli for wywołującej autofix. Przy napotkaniu status === 429, zamiast natychmiast przerywać i zwracać błąd, system poczeka np. 15-20 sekund i spróbuje ponownie, powiadamiając użytkownika toastem "Oczekiwanie na reset limitów AI...".

3. Wprowadzenie Staging Branch & Zmiany w CI/CD

Aby powstrzymać łamanie gałęzi main, wdrożymy model staging -> main.

[MODIFY] .github/workflows/ci.yml

  • Podział ról:
    • push na staging: Uruchamia pełny pipeline (Lint, Testy, Build) — bez publikacji na główny Render (zablokowany webhook).
    • push na main: Wykonywany tylko przy poprawnym PR ze staging. Obejmuje Deploy do Render.com.
  • Uproszczenie: Rozdzielenie zadań i upewnienie się, że deepeval nie blokuje wdrożeń (już ma continue-on-error, ale potwierdzimy jego poprawność).

User Review Required

Polityka Staging: Po zmianie ci.yml wymusimy, że bieżący development będzie odbywał się na gałęzi staging. Będziesz musiał tworzyć lokalne commity na staging, a na main przenosić kod przez PR na GitHubie. Czy zgadzasz się na zmianę Twojego workflow w Git, w którym main stanie się "świętą" gałęzią tylko dla działających wydań, a Ty będziesz pracował na staging?

Open Questions

  1. Staging Environment on Render: Czy posiadasz już przygotowany darmowy Web Service na platformie Render pod "Staging", czy mam w ci.yml pominąć automatyczny deploy ze staging do czasu ręcznego utworzenia tego środowiska przez Ciebie?
  2. Pre-commit: Uruchomienie pre-commit będzie wymagało od Ciebie lokalnego uruchomienia pre-commit install. Czy wolisz, abym stworzył prosty skrypt .bat/bash, który to zautomatyzuje podczas startu?

Verification Plan

  1. Ręczne wywołanie autofixu: Weryfikacja logów backendu, aby upewnić się, że po wdrożeniu poprawek do projects.py, do LLM wysyłane są tylko filtrowane issues pasujące do sekcji.
  2. Zasymulowanie 429 (Rate Limit): Wywołanie autofixu na wszystkich sekcjach pod rząd (bez przerw). Upewnienie się, że frontendowy backoff radzi sobie z zawieszeniem i wznawia proces.
  3. Instalacja hooków: Odpalenie próbnego złego commita i upewnienie się, że hook pre-push lub pre-commit go odrzuci.