Specyfikacja techniczna (ST)
Pożądany termin realizacji - 24 godziny (PILNE!)
Backend dla publicznej aplikacji internetowej z moderacją wiadomości tekstowych
1. Ogólny opis
Należy opracować backend dla aplikacji internetowej, która działa w jednym egzemplarzu, umieszczonym w przestrzeni publicznej (ekran / terminal / instalacja).
Aplikacja kliencka wysyła krótkie wiadomości tekstowe (analogiczne do SMS), które przechodzą moderację i po zatwierdzeniu są wyświetlane na ekranie.
Backend jest instalowany na osobnym komputerze i działa:
w lokalnej sieci razem z aplikacją kliencką;
lub z dostępem przez internet (opcjonalnie).
2. Wymagania architektoniczne i technologiczne
2.1 Ogólne wymagania
Technologie muszą być powszechnie stosowane i łatwe do wsparcia.
Zabronione jest używanie egzotycznych lub wąsko wyspecjalizowanych frameworków, które utrudniają przekazanie projektu innemu deweloperowi.
Rozwiązanie powinno być zrozumiałe dla zewnętrznego dewelopera bez długiego onboardingu.
2.2 Wdrożenie i wsparcie
Obowiązkowo:
możliwość szybkiego wdrożenia systemu;
możliwość prostego aktualizowania.
Dopuszczalne i pożądane opcje:
przechowywanie kodu w GitHub;
wdrożenie przez Docker / Docker Compose;
minimalna liczba ręcznych kroków przy aktualizacji.
Backend powinien działać:
na zwykłym komputerze (Windows / Linux);
bez zależności od specyficznej infrastruktury serwerowej.
3. Role i dostęp
3.1 Aplikacja kliencka
Dostęp:
wysyłanie wiadomości;
otrzymywanie listy zatwierdzonych wiadomości;
otrzymywanie statusu systemu.
Autoryzacja:
nieobowiązkowa lub realizowana przez prosty mechanizm (API-key, token).
3.2 Panel administracyjny (moderacja)
Jedyna rola — moderator.
Realizacja panelu administracyjnego — do wyboru dewelopera:
oddzielny panel webowy;
gotowy panel administracyjny;
lub inne standardowe podejście.
❗ Obecność oddzielnego publicznego API dla panelu administracyjnego nie jest obowiązkowa.
Główne wymaganie — funkcjonalność i łatwość wsparcia.
Funkcje moderatora:
przegląd wszystkich wiadomości;
zmiana statusu wiadomości;
edycja tekstu przed zatwierdzeniem;
zarządzanie stanem systemu aplikacji.
4. Dane i model wiadomości
4.1 Wiadomość (Message)
Pole Typ Opis
id string / UUID / int Unikalny identyfikator
original_text string Oryginalny tekst od klienta
approved_text string | null Tekst po moderacji
status enum pending / approved / rejected
created_at datetime Data i czas otrzymania
reviewed_at datetime | null Data moderacji
ai_checked boolean Czy przeszedł kontrolę AI
ai_result string | null Komentarz lub wynik kontroli AI
5. Stan systemu
5.1 SystemState
Pole Typ Opis
is_blocked boolean Czy ekran jest zablokowany
system_message string Wiadomość systemowa
updated_at datetime Data ostatniej zmiany
6. API dla aplikacji klienckiej (obowiązkowe)
6.1 Wysyłanie wiadomości
POST /api/messages
{
"text": "Krótkie wiadomości tekstowe"
}
{
"success": true,
"message_id": "12345"
}
6.2 Otrzymywanie zatwierdzonych wiadomości
GET /api/messages/approved
{
"messages": [
{
"id": "123",
"text": "Zatwierdzony lub edytowany tekst",
"created_at": "2026-01-08T10:15:00Z"
}
]
}
Zwracane są wyłącznie wiadomości ze statusem approved.
6.3 Otrzymywanie statusu systemu
GET /api/system/status
{
"is_blocked": true,
"system_message": "Tymczasowo niedostępne"
}
7. Automatyczna kontrola wiadomości przez AI (opcjonalnie)
Automatyczna kontrola tekstów przez OpenAI API.
Wynik kontroli jest przechowywany i dostępny dla moderatora.
AI nie podejmuje ostatecznej decyzji, tylko wspomaga moderację.
8. Ograniczenia i ochrona
Ograniczenie długości wiadomości (zalecane do 160–240 znaków).
Podstawowa ochrona przed spamem (rate-limit).
Walidacja danych wejściowych.
9. Oczekiwany wynik (MVP)
Działający backend z minimalnym API dla klienta.
Prosty panel administracyjny z jedną rolą.
Szybkie wdrożenie na komputerze.
Możliwość łatwego przekazania wsparcia innemu deweloperowi.
Gotowość do pracy zarówno w lokalnej sieci, jak i przez internet.
