plan.md

Moja rekomendacja – najlepsze podejście Hybrydowe wsparcie (nie sztywne reguły): System powinien robić obie rzeczy jednocześnie, ale w jasnej hierarchii:

Główna rekomendacja (zawsze na górze) Najlepiej dopasowany program do wskazanej potrzeby + profilu firmy. Z wysokim % match i wyraźnym uzasadnieniem „Dlaczego ten program pasuje właśnie do Ciebie”.

Szerokie spektrum możliwości (poniżej, jako „Inne warte rozważenia”) 3–5 dodatkowych programów, które mogą być interesujące dla tej firmy, nawet jeśli nie idealnie pasują do podanej potrzeby. Z krótkim wyjaśnieniem dlaczego warto je rozważyć (np. „Ten program jest popularny wśród firm z Twojej branży i województwa”).

Przykład odpowiedzi systemu: Główna rekomendacja Dotacja ZUS na poprawę BHP – Match 94% Idealnie pasuje do Twojej potrzeby poprawy warunków pracy. Firma średnia, produkcyjna, województwo mazowieckie – spełniasz wszystkie kryteria. Inne możliwości warte rozważenia dla Twojej firmy:

Program regionalny Mazowieckie „Modernizacja stanowisk pracy” (Match 78%) FENG – inwestycje w bezpieczeństwo i higienę pracy (Match 65%) Dotacja PARP na automatyzację procesów produkcyjnych (Match 59%)

To podejście daje formę wsparcia, a nie sztywne reguły:

Użytkownik, który wie dokładnie czego chce, dostaje od razu najlepszą opcję. Użytkownik, który jest otwarty na możliwości, dostaje szerszy kontekst i może odkryć coś, o czym nie myślał.

Jak to technicznie zrealizować (propozycja)

W agencie Matcher dodaj parametr user_need (opcjonalny tekst lub kategoria). Jeśli user_need jest podany → priorytet na programy pasujące do tej potrzeby. Zawsze dodawaj sekcję „Inne ciekawe programy dla Twojej firmy” (3–5 pozycji z niższym, ale nadal sensownym dopasowaniem).

To jest najbardziej użyteczne i „ludzkie” podejście – dokładnie takie, jakiego oczekuje konsultant lub właściciel firmy.

Plan Wdrożenia: Agencja Krytyka (Globalny Audyt Wniosku)

Zgodnie z uznanym Priorytetem 1, skupiamy się na zbudowaniu scentralizowanego weryfikatora (Audytora), który po wygenerowaniu wszystkich sekcji i skompilowaniu finalnego dokumentu, przeprowadzi kompleksową wieloaspektową walidację (weryfikacja krzyżowa).

Cel Biznesowy

Zastąpienie strachu użytkownika przed pomyłkami AI twardym "Świadectwem Zgodności". System na koniec upewnia się, że nie ma sprzeczności merytorycznych między sekcjami (np. koszty w Budżecie kontra zadania z wpisanego Harmonogramu Rzeczowo-Finansowego).

Propozycja Zmian Technicznych (Szczegóły)

1. Backend: Nowy Endpoint Audytu (projects.py)

Utworzenie nowego endpointu POST /api/projects/{project_id}/audit-final-document. Endpoint ten pobierze zawartość project.final_document_markdown i uruchomi nowy potok decyzyjny LLM + RAG. Zmiany obejmą również:

• Modyfikację schematu bazy danych (Opcjonalnie): Dodanie pola final_document_audit_result (typu JSON) w modelu Project, by persystować wynik audytu wniosku, co pozwoli na jego późniejsze wyświetlenie bez konieczności ponownego generowania audytu.

2. Backend: Agent Audytora (agents/project_qa_agent.py lub agents/auditor.py)

Stworzenie dedykowanej funkcji audit_final_document(project_id, content), która realizuje:

• Weryfikację krzyżową (Cross-Check): Budżet vs Harmonogram.
• Bezpieczeństwo formalne z RAG (wymuszone szukanie zapytań wektorowych np. "katalog kosztów kwalifikowalnych dla {PROGRAM_NAME}").
• Zwracanie uporządkowanej struktury w formacie JSON (OutputParser) zawierającej ocenę dla kilku wymiarów, w tym m.in. spójności budżetu, spójności DNSH (Zasada Do No Significant Harm) czy kompletności opisów.

[NEW] Struct JSON Response (Format docelowy)

{
  "is_approved": false,
  "overall_score": 75,
  "issues": [
    {
      "category": "Budżet",
      "severity": "high",
      "message": "Użyto pojęcia 'wydatki na ubezpieczenia samochodowe', co jest wykluczone w ścieżce SMART według par. 4 Regulaminu."
    },
    {
      "category": "DNSH",
      "severity": "low",
      "message": "Opis DNSH jest trochę zbyt ogólnikowy dla Celu 5 (Zanieczyszczenia powietrza)."
    }
  ]
}

3. Frontend: Panel Audytu w FinalDocumentPanel.tsx

Wprowadzenie dedykowanej sekcji (Auditor UI) ponad podglądem wygenerowanego dokumentu.

• Dodanie przycisku Przeprowadź Globalny Audyt Wniosku obok przycisku kompilacji.
• Po wykonaniu audytu wyświetleni kart alarmowych / ostrzegawczych w przejrzystym layoutcie, wspieranym odpowiednią kolorystyką zależnie od powagi problemu (severity - high, medium, low).
• Przycisk "Zastosuj rekomendacje / Wróć do sekcji", który ułatwi powrót do poprawienia wskaźników przez użytkownika.

User Review Required

Proszę o zgodę na to podejście techniczne.

Jedno ważne pytanie: W przypadku znalezienia błędów krytycznych – czy "Audytor" w tej iteracji ma tylko flagować i wskazywać błędy (Read-Only) czy ma mieć opcję automatycznej interwencji (z nadpisaniem części wniosku bez zgody użytkownika)? Zgodnie ze standardami "biura konsultingowego", mądrzej byłoby tylko informować i przekierowywać klienta z powrotem do Edytora Sekcji (aby mógł ręcznie zastosować poprawki, generując ponownie zawartość sekcji mając już w głowie komentarz audytora). Czy zgadzasz się z takim zachowaniem (Read-Only flags)?

Plan Weryfikacji

Zastosujemy test polegający na dodaniu celowego błędu bezpośrednio do jakiejkolwiek sekcji przed złączeniem pliku, by sprawdzić po zrzeszeniu wszystkich fragmentów we wniosku wspólnym, że nowo założony audytor faktycznie wychwyci błąd i wyróżni go po stronie FrontEnd.

Plan wdrożenia na szerszy rynek – GrantForge AI (DotacjeAI) Na podstawie dostarczonego strategicznego raportu przygotowałem konkretny, priorytetowy i realistyczny plan wdrożeniowy od strony aplikacji. Skupiam się wyłącznie na tym, co musimy zmienić, poprawić i dołożyć w kodzie i architekturze, żeby system był gotowy na skalowanie (tysiące użytkowników, firmy IT, startupy, agencje doradcze). Priorytety wdrożenia (High → Low) HIGH PRIORITY (musimy zrobić jako pierwsze – 4–6 tygodni)

Globalny Audytor Wniosku + Wzmocniony Agent Critic Wdrożenie modułu, który po wygenerowaniu wszystkich sekcji robi krzyżową weryfikację spójności całego wniosku (budżet vs harmonogram vs DNSH vs cele projektu vs regulamin). Dodanie progu ufności (confidence threshold 90–95%). Przy niższej pewności – automatyczna flaga + eskalacja do Human-in-the-loop. Wizualny „Audyt Zgodności” w panelu „Gotowy Wniosek” (zielone/czerwone znaczniki przy każdej sekcji + uzasadnienie).

Transparentność AI (zgodność z AI Act Art. 13) Na każdym wygenerowanym fragmencie dodać widoczny disclaimer: „Treść wygenerowana przez AI na podstawie regulaminów z dnia [data]. Zalecana ostateczna weryfikacja przez doradcę/prawnika.” W ustawieniach konta opcja „Pokaż zawsze informacje o AI”.

RODO & Privacy by Design Wprowadzenie mechanizmu „prawo do bycia zapomnianym” (usuwanie wszystkich danych użytkownika + wektorów w Pinecone na żądanie). Szyfrowanie danych wrażliwych (opisy projektów, dane finansowe). Logowanie zgód na przetwarzanie danych (w bazie).

MEDIUM PRIORITY (po High – 3–5 tygodni)

Ulepszony Scoring na starcie + Explainable AI Matcher musi zwracać nie tylko % match, ale uzasadnienie („Dlaczego ten program dostał 94% – spełniasz kryteria MŚP, województwo, branża C28”). Wprowadzenie reguł sztywnych z RAG (wykluczenia PKD, limity de minimis, wiek firmy itp.).

Integracja z oficjalnymi API PARP i NCBR API do automatycznego zasilania bazy wiedzy (zamiast tylko scrapingu). GUS/REGON/KRS – już masz, ale upewnij się, że dane są cache’owane i aktualizowane.

Model monetyzacji – dopracowanie pakietów Starter (Freemium) – tylko profiling + wstępny scoring. Professional – pełny edytor, Critic, Q&A, eksport. Enterprise – white-label dla agencji + API access. Micro-payments za dodatkowe iteracje poza limitem.

LOW PRIORITY (po MVP)

Certyfikacja ISO 27001 (długoterminowo). Ubezpieczenie OC IT (można zrobić wcześniej, ale nie blokuje launchu). Zaawansowane funkcje (budżetowanie tabelaryczne, Gantt, kalkulator kwalifikowalności).

Co musimy zmienić / poprawić / dołożyć (konkretna lista) Zmienić / Poprawić:

Agent Critic – z poziomu sekcji na poziom całego wniosku (Global Auditor). Prompt Matcher – dodać Explainable AI (uzasadnienie scoringu). Disclaimer AI – dodać na każdym generowanym fragmencie i finalnym wniosku. Privacy – mechanizm usuwania danych użytkownika na żądanie.

Dołożyć:

Tabela ProjectSectionTemplate jest już, ale dodaj pole ai_prompt_template per sekcja/program. Endpoint /api/projects/{id}/global-audit (weryfikacja krzyżowa całego wniosku). Widoczny „Audyt Zgodności” w panelu „Gotowy Wniosek”. Opcję „Human Review” przy niskiej pewności modelu.

Kolejność na najbliższe 6–8 tygodni (propozycja sprintów): Sprint 1 (Zakończony wdrożeniem na Github+Render)

• Globalny Audytor Wniosku + Explainable Scoring

Sprint 2 (✅ UKOŃCZONY)

• RODO / Privacy by design (DELETE /api/account, eksport danych, anonimizacja PII)
• Transparentność AI (disclaimery, audit_logger, AI Act Art. 13)
• Endpoint DELETE /api/projects/{id}/audit

Sprint 3 (✅ UKOŃCZONY - 2026-04-15)

• Naprawiono bug: autofix czytał z nieistniejącego pola DB
• Naprawiono ścieżki importów w agentach (backend.core → try/except)
• SSE Generator — poprawne event shapes (section_completed, document_done)
• AIGeneratorPanel — window.confirm zastąpiony toast confirmation
• ProjectAuditPanel — przycisk „Przejdź do sekcji" + toast zamiast alert
• ProjectWorkspace — auto-przełączenie na Sekcje po Autopilocie AI
• navigate-to-section event system (audit → workspace navigation)
• DocumentBuilder — metadane + AI disclaimer stopka
• generator_agent.py — dict copy fix + markdown cleanup
• README_TESTERS.md — 6 pełnych scenariuszy testowych

Sprint 4 (NASTĘPNY) Integracja z API PARP/NCBR + finalne testy + regulamin SaaS

• Klient HTTP do PARP API (aktywne nabory)
• Klient HTTP do NCBR API
• Cache naborów (TTL 24h)
• Auto-sync RAG po aktualizacji naborów
• Strony /regulamin i /polityka-prywatnosci
• Testy E2E z Playwright
• Health check endpoint /api/health
• Rate limiting na generatorze i audytorze Sprint 4 (UKOŃCZONY - 2026-04-15) Integracja z API PARP/NCBR + regulamin SaaS + infrastruktura
• Klient HTTP do PARP API (aktywne nabory) — core/parp_client.py
• Klient HTTP do NCBR API — core/ncbr_client.py
• Cache naborów (TTL 24h) — plik JSON w cache/, bez Redis
• Endpoint /api/grants/nabory — scalone PARP + NCBR (asyncio.gather)
• Endpoint /api/grants/match — matching z projektem (score % + powody)
• Health check /api/health — DB latency, LLM config, Pinecone, klucze zewnętrzne
• Rate limiting middleware — sliding window per user
• Interceptor 429 w frontend (Axios) — toast z retry_after
• Strona /regulamin — pełna treść ToS, publiczna
• Strona /polityka-prywatnosci — RODO/GDPR compliance
• Stopka LandingPage z linkami prawnymi

Sprint 6 (✅ UKOŃCZONY - 2026-04-15) — Enterprise Architecture

• SensitiveDataGuard — IBAN, Email, PESEL, OSOBA, ADRES (FAZA 1)
• Generator: anonymize→LLM→deanonymize pipeline — project_description anonimizowany przed LLM (FAZA 1)
• GlobalAuditOutput + confidence_score + human_review_required (FAZA 4)
• multi_perspective_audit() — 3 role: Prawnik, Finansista, Innowator (FAZA 5)
• LangSmith konfiguracja — langsmith_config.py + env + server startup (FAZA 6)
• tests/test_deepeval_rag.py — DeepEval faithfulness test (FAZA 6)
• .env.example — pełny szablon (17+ kluczy, BIELIK_MODE, LLAMA_CLOUD_API_KEY)
• Dockerfile — multi-stage (Node builder + Python slim + non-root + healthcheck)
• React ErrorBoundary — globalny wrapper (FAZA 6)
• Cookie Consent Banner — RODO Art.7, 3 kategorie, localStorage z wersjonowaniem (FAZA 1)
• LlamaParse waterfall: LlamaParse → PyPDF → Unstructured (FAZA 2)
• Hierarchical Chunking §/Art./Rozdział — Parent 2000 / Child 400 (FAZA 2)
• MultiVectorRetriever — Pinecone child + LocalFileStore parent (FAZA 2)
• LLM Router + Bielik 11b — ollama/huggingface/disabled + with_fallbacks() (FAZA 4)
• /api/health — Bielik status, LlamaParse, LangSmith, GUS (v1.3.0)

Sprint 7 (✅ UKOŃCZONY - 2026-04-15) — Deploy + Upload PDF + CI/CD

• render.yaml — pełna konfiguracja Render.com (Gunicorn, PostgreSQL addon, disk, healthcheck, wszystkie env vars)
• requirements.txt — dodano pypdf, llama-parse, langchain-huggingface, deepeval; usunięto torch/streamlit (RAM OOM)
• ProjectDocument model — DB tracking statusu RAG per dokument (uploaded/processing/indexed/error)
• Endpoint POST /api/projects/{id}/documents — upload PDF + pipeline RAG w tle (asyncio.create_task)
• Endpoint GET /api/projects/{id}/documents — lista dokumentów ze statusem
• Endpoint POST /api/projects/{id}/documents/{doc_id}/reingest — ponowna indeksacja
• Endpoint DELETE /api/projects/{id}/documents/{doc_id} — usunięcie z dysku i DB
• .github/workflows/ci.yml — 6-etapowy pipeline CI/CD (lint→test→deepeval→frontend→docker→deploy)

Sprint 8 (✅ UKOŃCZONY - 2026-04-15) — UI Upload + Widget Nabory + Migracja

• React: DocumentUploadPanel — drag & drop, walidacja PDF, polling statusu co 3s
• React: zakładka "Dokumenty RAG" w ProjectWorkspace (tab Database)
• React: MatchingGrantsWidget — top 3 nabory dopasowane do programu projektu
• Widget zintegrowany na zakładce Podsumowanie projektu (sidebar-style)
• Alembic migration 0004 — tabela project_documents (status, chunks, namespace)

Sprint 9 (✅ UKOŃCZONY - 2026-04-15) — Produkcja & Testy

• Rate limiting endpointu upload — max 10 plików/projekt (hard) + plan-aware (Free: 3, Pro: 50)
• GET /documents zwraca pole quota z informacjami o limicie dla frontendu
• DocumentUploadPanel — licznik kwoty (current/limit · PLAN), blokada drop zone przy limicie
• Obsługa HTTP 429 w upload z czytelnym komunikatem i linkiem do /cennik
• tests/test_upload_rag_e2e.py — testy E2E: upload, limity, struktura quota
• DEPLOYMENT.md — pełna instrukcja GitHub Secrets + Render.com env vars + Alembic
• Konfiguracja GitHub Secrets (RENDER_DEPLOY_HOOK_*, PINECONE_*, LANGCHAIN_API_KEY) — MANUALNIE
• Deploy na Render.com + alembic upgrade head + weryfikacja /api/health — MANUALNIE

Sprint 10 (W TRAKCIE - 2026-04-16) — Monitoring & Launch

• LangSmith dashboard — konfiguracja alertów (faithfulness < 0.7)
• Render.com — konfiguracja custom domain (grantforge.pl)
• Stripe Webhook — weryfikacja produkcyjna
• Strona /cennik — porównanie planów Free/Pro/Enterprise z Stripe checkout (Pricing.tsx + Pricing.css)
• Backend POST /api/subscription/checkout — Stripe Session creator (stripe_webhooks.py)
• Beta invite — email do 10-50 testerów
• Monitoring 429 — alert gdy >10% requestów to "limit exceeded"
• CI/CD pipeline — fix lint (ruff auto-fix 625 issues, ignore list dla legacy code) ✅ commit 72f095d
• GitHub Secrets — 7/7 skonfigurowanych (GitHub MCP) ✅
• Render Deploy Hooks — backend + frontend ✅