Projekt na HackYeah 2026, przygotowany dla wyzwania Regionalnego Ośrodka Polityki Społecznej w Krakowie. Splot łączy opis lokalnej potrzeby z katalogiem innowacji społecznych, pomaga przygotować plan adaptacji i obsługuje zgłoszenia kierowane do ROPS. Repozytorium zachowuje nazwę Hubmi; w interfejsie aplikacji używana jest nazwa Splot.
Frontend działa w Next.js 16 i React 19, backend w FastAPI. Supabase zapewnia bazę PostgreSQL, logowanie i uprawnienia do danych. Backend korzysta z usług AI do dopasowania innowacji i generowania planów adaptacji.
- Uruchom aplikację według instrukcji poniżej i otwórz stronę główną.
- Wpisz potrzebę, np. „W naszej gminie osoby starsze mieszkające samotnie potrzebują regularnych spotkań i wsparcia”. Sprawdź dopasowania, ich uzasadnienia i linki źródłowe. Przy wybranym rozwiązaniu rozwiń „Plan adaptacji AI” i podaj lokalny kontekst.
- Otwórz Zasobnik Wiedzy: przejrzyj innowacje, materiały i wyzwania regionalne. Sprawdź wyszukiwanie oraz filtry.
- Zaloguj się kontem autora. W kreatorze pomysłu zapisz fiszkę, następnie odczytaj ją w Moich zgłoszeniach, także po odświeżeniu strony.
- W osobnej sesji przeglądarki zaloguj się kontem ROPS. W panelu ROPS otwórz tę fiszkę, zmień status, dodaj oficjalną odpowiedź i wiadomość w rozmowie. Wróć do konta autora i sprawdź odpowiedzi.
- Przejdź przez pozostałe ścieżki: zgłoszenie potrzeby, zgłoszenie do pilotażu oraz wniosek w naborze. Odpowiadające im widoki pracownika ROPS są opisane w tabeli poniżej.
Do pełnego przebiegu potrzebne są skonfigurowana baza oraz konta autora i pracownika ROPS przygotowane przez zespół. Hasła nie są częścią repozytorium. Nabór oznaczony jako demonstracyjny służy do prezentacji — złożenie w nim wniosku nie oznacza udziału w oficjalnym konkursie.
Adresy w tabeli zakładają lokalny frontend na porcie 3000. [id] oznacza identyfikator zapisanego rekordu; do szczegółów prowadzą linki na listach.
| Ekran | Adres | Co można sprawdzić |
|---|---|---|
| Znajdź rozwiązania | /#wyszukaj | Opis potrzeby, dopasowane innowacje, uzasadnienia, źródła i plan adaptacji AI. |
| Zasobnik Wiedzy | /baza-wiedzy | Katalog innowacji i materiałów, wyszukiwanie, kategorie i wyzwania regionalne. |
| Zgłoś potrzebę | /zglos-potrzebe | Formularz lokalnej potrzeby oraz odczyt własnych zgłoszeń po zalogowaniu. |
| Zgłoś pomysł | /kreator | Fiszka: potrzeba, rozwiązanie, odbiorcy, etap i opcjonalne powiązanie z innowacją. |
| Moje zgłoszenia | /moje-zgloszenia | Własne fiszki; szczegóły, status, oficjalna odpowiedź i rozmowa w /moje-zgloszenia/[id]. |
| Tester innowacji | /tester | Zgłoszenie instytucji do pilotażu, własne zgłoszenia, opinie i podsumowania ocen. |
| Wniosek w naborze | /wnioski | Nabory i własne wnioski; edycja w /wnioski/[id], druk i eksport TXT w /wnioski/[id]/podglad. |
| Logowanie | /logowanie | Logowanie istniejącym kontem Supabase przez email i hasło. |
| Panel ROPS | /rops | Lista fiszek z filtrami; szczegóły, zmiana statusu i kontakt z autorem w /rops/zgloszenia/[id]. |
| ROPS: baza wiedzy | /rops/innowacje | Tworzenie i edycja innowacji oraz zarządzanie materiałami: weryfikacja, publikacja i wycofanie. |
| ROPS: potrzeby regionu | /rops/potrzeby | Lista potrzeb, zestawienia, statusy i wewnętrzne notatki. |
| ROPS: pilotaże | /rops/tester | Obsługa zgłoszeń testowych, zmiana statusów i notatki ROPS. |
| ROPS: wnioski | /rops/wnioski | Lista z filtrami i odczyt wniosku w /rops/wnioski/[id]. |
Gość może korzystać z wyszukiwarki i publicznych materiałów. Zapisy oraz prywatne listy wymagają logowania. Panel pracownika wymaga roli app_metadata.hubmi_role=rops_admin nadanej po stronie serwera. Sam adres email ani przejście na /rops nie nadają uprawnień.
Wymagania: Node.js 20.9 lub nowszy (zalecany 22), npm, Python 3.11 lub nowszy oraz projekt Supabase. Pełna ocena wymaga tabel, migracji, danych katalogu i kont Supabase Auth. Pliki .env.example zawierają przykłady konfiguracji, bez danych dostępowych.
W katalogu głównym repozytorium:
cd backend
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .envPrzed uruchomieniem uzupełnij backend/.env:
| Zmienna | Znaczenie |
|---|---|
SUPABASE_URL |
Adres projektu Supabase używanego również przez frontend. |
SUPABASE_KEY |
Klucz serwerowy do operacji backendu; dla pełnej obsługi administracyjnej klucz service_role. |
GEMINI_API_KEY / OPENAI_API_KEY |
Klucze dostawców AI. Przebieg opisany w raporcie końcowym korzystał z Gemini. |
GEMINI_EMBEDDING_MODEL, GEMINI_GENERATION_MODEL, GEMINI_GENERATION_FALLBACK_MODELS |
Wybór modeli; wartości domyślne są w pliku przykładowym i konfiguracji backendu. |
CORS_ORIGINS |
Dozwolone adresy frontendu; przykład obejmuje http://localhost:3000. |
Następnie:
python run.pyAPI: http://localhost:8000. Swagger zawiera aktualne endpointy i schematy żądań. Health check pozwala sprawdzić m.in. supabase_connected.
W drugim terminalu, z katalogu głównego repozytorium:
cd frontend
npm ci
cp .env.example .env.localUzupełnij frontend/.env.local:
NEXT_PUBLIC_BACKEND_URL=http://localhost:8000
NEXT_PUBLIC_USE_MOCK_MATCHING=false
NEXT_PUBLIC_SUPABASE_URL=https://TWOJ-PROJEKT.supabase.co
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=PUBLICZNY_KLUCZ_PROJEKTU
NEXT_PUBLIC_SUBMISSIONS_ENABLED=true
NEXT_PUBLIC_ROPS_COMMUNICATION_ENABLED=truePubliczny klucz NEXT_PUBLIC_SUPABASE_ANON_KEY jest obsługiwany jako alternatywa dla publishable key. Klucz service_role pozostaje wyłącznie w backendzie. Adres backendu podaj bez końcowego /api.
Flagi zapisu fiszek i komunikacji włączaj w środowisku z wdrożonym schematem, triggerami i politykami RLS. W pliku przykładowym są wyłączone. Po zmianie zmiennych zrestartuj serwer; dla wersji produkcyjnej wykonaj ponownie build.
npm run devOtwórz http://localhost:3000.
Schemat początkowy znajduje się w backend/supabase_schema.sql, a kolejne zmiany w backend/migrations/, numerowane od 02 do 12. Obejmują m.in. fiszki i wiadomości, role i RLS, pilotaże, potrzeby, nabory i materiały wiedzy. Przy przygotowywaniu nowej bazy zastosuj schemat i migracje w kolejności numerów; samo uruchomienie serwerów nie tworzy tych tabel ani kont.
Dane katalogu są w backend/scripts/data/innovations.json, a import w backend/scripts/seed_data.py. Z katalogu backend/ można najpierw sprawdzić plik bez zapisu:
python scripts/seed_data.py --dry-runImport do skonfigurowanej bazy wykonuje python scripts/seed_data.py. Tworzy embeddingi i zapisuje rekordy, więc wymaga dostępu do bazy i dostawcy AI. Konta użytkowników i rolę pracownika ROPS przygotowuje się oddzielnie w Supabase Auth.
Z katalogu frontend/:
NEXT_PUBLIC_USE_MOCK_MATCHING=true npm run devWybierz przykład „Samotność seniorów” lub „Dostępność wsparcia”. Ten tryb pokazuje oznaczone, fikcyjne dopasowania z mock-matching.ts. Obejmuje wyłącznie wyszukiwarkę; plan AI, logowanie i zapisy wymagają rzeczywistych usług. Błąd prawdziwego API nie przełącza aplikacji na dane demonstracyjne.
| Obszar | Frontend | Backend |
|---|---|---|
| Strony i nawigacja | src/app/, site-header.tsx | app/main.py, router.py |
| Dopasowania i adaptacja | matching-form.tsx, adaptation-form.tsx, lib/api.ts | match.py, middleman.py, services/ai.py |
| Fiszki i rozmowy | features/submissions/, features/messages/, features/rops/ | submissions.py, admin.py |
| Potrzeby regionu | features/needs/ | needs.py, services/needs.py |
| Pilotaże i oceny | features/tester/ | testing.py, services/testing.py |
| Wnioski w naborach | features/grants/ | grant_applications.py, services/grant_applications.py |
| Zasobnik Wiedzy | features/knowledge/ | innovations.py, knowledge_resources.py |
| Logowanie i uprawnienia | features/auth/, lib/supabase/ | core/security.py, migrations/ |
| Kontrakt danych | Modele i serwisy w poszczególnych features/ |
models/schemas.py |
| Testy | tests/, tests/e2e/ | tests/ |
Frontend odczytuje i zapisuje fiszki oraz rozmowy przez klienta Supabase. Pozostałe moduły korzystają z FastAPI; autoryzowane żądania przekazują sesję Supabase. Z tego powodu ocena uprawnień obejmuje zarówno backend, jak i polityki RLS bazy.
Raport końcowego przebiegu z 4 października 2026 opisuje testy na rzeczywistym Supabase i Gemini: dopasowanie, plan adaptacji, obieg fiszki, potrzeby, pilotaże, wnioski oraz publikację materiałów. Zawiera wyniki kontroli izolacji kont autora A/B i ROPS oraz rozróżnia testy integracyjne od testów na atrapach. Są to wyniki zapisane w raporcie, nie automatyczne potwierdzenie dowolnego nowego środowiska.
Raport odnotowuje poprawne demo lokalne oraz blokadę publicznego dostępu do wdrożenia przez ekran logowania Vercel. Do odtworzenia oceny służą adresy lokalne podane wyżej; wcześniejsze linki do tymczasowych tuneli nie są stałym adresem projektu.
Kontrole frontendu, wykonywane w frontend/:
npm test
npm run lint
npx tsc --noEmit
npm run buildIzolowane regresje końcowego przebiegu, wykonywane w backend/ z aktywnym środowiskiem Python:
pytest -q tests/test_demo_readiness.py tests/test_embedding_failure_regression.py tests/test_knowledge_edit_regressions.pyPełny zestaw backendu jest w backend/tests/; część testów sprawdza rzeczywiste połączenie lub RLS i wymaga przygotowanej bazy testowej. Scenariusze przeglądarkowe w frontend/tests/e2e/ wymagają uruchomionych usług, Playwright/Chromium i kont testowych — opis przygotowania i zakres wyników znajduje się w raportach.
Dokumenty pomocnicze:
- Etap 6: Zasobnik Wiedzy i ROPS — publikacja i wycofywanie materiałów, widoczność szkiców, źródła i izolacja kont.
- Generator wniosków — pola wzoru, zapis, podgląd, eksport i scenariusze naborów.
- Potrzeby regionu — kontrakt API — zgłaszanie potrzeb i zestawienia dla ROPS.
- Wdrożenie backendu — konfiguracja hostingu, CORS i kontrola połączenia.
- Szacunek kosztów utrzymania — założenia kosztorysu.
Dokumenty z wcześniejszych etapów zachowują stan integracji z chwili ich napisania. Przy rozbieżnościach dotyczących gotowości funkcji korzystaj z raportu etapu 7, a dla endpointów, pól i zmiennych — z bieżącego kodu oraz Swaggera uruchomionego backendu.