implementation_plan.md

# 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`](file:///c:/Users/amazu/Desktop/ANTIGRAVITY/DOTACJE/.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`](file:///c:/Users/amazu/Desktop/ANTIGRAVITY/DOTACJE/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`](file:///c:/Users/amazu/Desktop/ANTIGRAVITY/DOTACJE/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`](file:///c:/Users/amazu/Desktop/ANTIGRAVITY/DOTACJE/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`](file:///c:/Users/amazu/Desktop/ANTIGRAVITY/DOTACJE/.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

> [!WARNING]
> **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.