Executive Summary

Przeprowadzono pełną inżynierię odwrotną lokalnego środowiska Leantime na podstawie konfiguracji, stanu runtime, logów, sieci, wolumenów, bazy danych, kodu zawartego w obrazie oraz zachowania aplikacji HTTP.

Obraz systemu

Badany system jest jednowęzłową instalacją aplikacji do zarządzania projektami i pracą zespołu. Kontener aplikacyjny łączy nginx, PHP-FPM, Leantime i scheduler; drugi kontener zapewnia MySQL. Jedynym publicznym punktem wejścia jest http://localhost:8080, a baza pozostaje dostępna wyłącznie wewnątrz sieci Compose.

Końcowa weryfikacja wykazała stan healthy dla obu kontenerów, brak restartów, przekierowanie niezalogowanego użytkownika do formularza logowania oraz odpowiedź HTTP 200 dashboardu po uwierzytelnieniu.

Zakres funkcjonalny

Leantime wspiera projekty, cele, kamienie milowe, zadania, Kanban, kalendarz, sprinty, ewidencję czasu, raporty, wiki, pliki, komentarze, powiadomienia i administrację użytkownikami. System stosuje sześciopoziomowy model ról od Read Only do Owner.

Stan danych

Instancja ma charakter demonstracyjny: zawiera jednego właściciela, projekt My Project i jedenaście elementów pracy, głównie onboarding. Brak klientów, wpisów czasu, sprintów, komentarzy i plików biznesowych. Dane nie reprezentują kompletnego procesu organizacji.

Kluczowe decyzje rekonstrukcyjne

• Przypiąć obrazy do zaobserwowanych digestów zamiast używać ruchomych tagów.
• Wygenerować nowe sekrety; nie przenosić wartości z prywatnego .env.
• Preferować czystą inicjalizację i jawny seed zamiast kopiowania anomalii danych.
• Uzgodnić strefę czasową i decyzję o telemetrii przed odbiorem.
• Potwierdzić rezultat pełnym zestawem testów funkcjonalnych i operacyjnych.

Discovery środowiska

Metoda i zakres

Discovery wykonano 20 czerwca 2026 r. w katalogu /home/pawel/lab/leantime-reverse-engineering-10. Analiza objęła pliki, efektywną konfigurację Compose, kontenery, obrazy, procesy, sieć, porty, wolumeny, logi, bazę i sesję HTTP. Hasła oraz klucze nie są powielane w raporcie.

Artefakty wejściowe

Katalog nie był repozytorium Git. Istniały starsze wolumeny z prefiksem leantime0_, lecz nie należały do aktywnego projektu.

Kontenery i obrazy

Sieć, porty i trwałość

Sieć bridge leantime-net używa podsieci 172.18.0.0/16. Aplikacja miała IP 172.18.0.3, baza 172.18.0.2. DNS Compose rozwiązuje mysql_leantime. Tylko TCP 8080 jest publikowany na IPv4 i IPv6; 3306/33060 pozostają wewnętrzne.

Baza i dane

Schemat obejmuje 35 tabel dotyczących użytkowników, ról, projektów, zadań, sprintów, czasu, kalendarza, plików, wiki, powiadomień, raportów, integracji, kolejek i audytu.

Weryfikacja HTTP i logów

• GET / zwracał 302 do /auth/login.
• Formularz logowania zawierał CSRF, e-mail, hasło i reset hasła.
• Poprawne uwierzytelnienie utworzyło sesję; GET /dashboard/home zwrócił 200.
• Dashboard potwierdził projekt i menu Dashboard, Project Hub, Timesheets, Calendar.
• Logi wykazały historyczne błędy instalacji/awatara i ostrzeżenia deprecacyjne, lecz zdrowy bieżący runtime.

Analiza komponentów

Warstwa aplikacyjna

Kontener leantime jest autonomicznym pakietem runtime. tini inicjuje skrypt startowy, a Supervisor utrzymuje nginx, PHP-FPM i php bin/leantime schedule:work. Nginx realizuje front HTTP, PHP-FPM wykonuje aplikację, a scheduler obsługuje kolejki e-mail, HTTP/default, telemetrię, ingestion i kontrolę licencji.

Warstwa danych

MySQL 8.4.10 jest krytyczną zależnością i trwałym źródłem prawdy dla encji domenowych, uprawnień i ustawień. Używa utf8mb4 oraz kolacji utf8mb4_unicode_ci. Healthcheck bazy steruje kolejnością startu aplikacji.

Warstwa plikowa

Cztery wolumeny aplikacji oddzielają pliki prywatne, publiczne, wtyczki i logi od obrazu. Dzięki temu wymiana kontenera nie powinna usuwać stanu. Backup bazy bez plików albo plików bez bazy nie zapewnia pełnej spójności funkcjonalnej.

Zależności runtime

Konfiguracja, produkt i dane

Research

Charakter systemu

Leantime jest webowym systemem organizacji pracy łączącym zarządzanie projektami, zadaniami i celami. Kod, UI, migracje oraz procesy tła są dostarczane wewnątrz obrazu, a nie w katalogu operatora.

Model informacji

Centralnym kontekstem jest projekt. Użytkownicy otrzymują członkostwo, a elementy pracy tworzą strukturę rezultatu: zadanie należy do kamienia milowego, a kamień milowy mierzy cel. Zadanie może posiadać opis, kryteria akceptacji, priorytet, status, wykonawcę, daty, estymaty, tagi, sprint i zależności.

Domeny biznesowe

1. Portfel i projekty: tworzenie projektów, Project Hub, daty, budżety i członkostwo.
2. Planowanie: cele, milestones, zadania, priorytety, terminy i zależności.
3. Realizacja: Kanban, statusy, wykonawcy, sprinty, komentarze i załączniki.
4. Plan osobisty: dashboard, kalendarz, własne zadania i timesheety.
5. Współpraca: komentarze, wiki/notatki, reakcje, powiadomienia i pliki.
6. Kontrola: statystyki, raporty, czas i zatwierdzenia.
7. Administracja: role, uprawnienia, ustawienia, wtyczki, integracje i tokeny.

Dane demonstracyjne

Wszystkie obecne dane biznesowe sklasyfikowano jako demonstracyjne. Wskazują na to lokalna domena konta, nazwa projektu, onboardingowe tytuły, zadania rekonstrukcyjne, fikcyjny kontekst ACME i brak aktywności w pozostałych domenach. reconstruction-volume-test.txt jest markerem technicznym, nie załącznikiem użytkownika.

Architektura logiczna

Topologia

Przepływ żądania

1. Przeglądarka wysyła żądanie HTTP do hosta na porcie 8080.
2. Docker przekazuje ruch do nginx w kontenerze aplikacji.
3. Nginx przekazuje obsługę dynamiczną do PHP-FPM i Leantime.
4. Aplikacja weryfikuje sesję i uprawnienia, korzysta z MySQL oraz plików.
5. Odpowiedź HTML/API wraca do przeglądarki; scheduler niezależnie obsługuje pracę cykliczną.

Właściwości jakościowe

Plan rekonstrukcji

Wymagania

• Docker Engine lub Docker Desktop oraz Compose v2; host Linux, WSL lub macOS.
• Architektura amd64 albo uprzednio zweryfikowane obrazy alternatywne.
• Minimum około 3 GB na obrazy oraz zapas na bazę i logi.
• Wolny port TCP 8080 i dostęp do registry lub lokalnych obrazów.
• Generator sekretów, prywatny .env, backup i narzędzie HTTP.

Artefakty docelowe

1. Compose z obrazami przypiętymi do digestów.
2. .env.example bez sekretów oraz chroniony .env.
3. Jawny, wersjonowany seed danych inicjalnych.
4. Procedura backup/restore bazy i czterech wolumenów aplikacji.
5. Automatyczny smoke test health, HTTP i liczników danych.

Kolejność uruchomienia

Inicjalizacja danych

Kontrole techniczne

docker compose config --quiet
docker compose up -d
docker compose ps
curl -fsS -o /dev/null http://localhost:8080/auth/login
docker compose exec leantime php bin/leantime about --only=environment
docker compose exec mysql_leantime mysql -u"$LEAN_DB_USER" -p -D leantime \
  -e 'SELECT COUNT(*) users FROM zp_user; SELECT COUNT(*) projects FROM zp_projects;'

Hasła należy przekazywać interaktywnie lub przez mechanizm secrets. Nie powinny znajdować się w historii powłoki ani w raporcie.

Kryteria odbioru

• Oba kontenery healthy, zero nieplanowanych restartów; opublikowany tylko port 8080.
• Poprawne logowanie, wersje, role, projekt i uzgodnione dane seed.
• Spójne działanie dashboardu, zadań, Kanbanu, kalendarza i przypisań.
• Trwałość po restarcie i poprawny restore na izolowanych wolumenach.
• Brak nowych production.ERROR w przebiegu odbiorowym.

Projekt funkcjonalny

Cel systemu

System wspiera planowanie, realizację i kontrolę pracy projektowej w jednej przestrzeni współpracy. Pozwala przełożyć cele na kamienie milowe i zadania, przydzielać odpowiedzialność, monitorować terminy i postęp oraz udostępniać wiedzę zespołowi.

Zakres funkcjonalny

• zarządzanie użytkownikami, rolami, klientami i dostępem projektowym;
• tworzenie i prowadzenie projektów, celów, kamieni milowych i zadań;
• Kanban, sprinty, kalendarz, statusy, priorytety, terminy i estymaty;
• dashboardy, raportowanie i ewidencja czasu pracy;
• komentarze, pliki, notatki/wiki i powiadomienia;
• ustawienia organizacji, integracje i rozszerzenia dla uprawnionych osób.

Poza zakresem podstawowym pozostają księgowość, fakturowanie, kadry, repozytorium kodu, komunikator czasu rzeczywistego i automatyzacja wdrożeń.

Aktorzy

Główne funkcje

Reguły biznesowe

• E-mail użytkownika jest unikalny, a sesję może rozpocząć tylko konto aktywne.
• Operacja wymaga odpowiedniej roli i dostępu do projektu.
• Zadanie należy do projektu, a jego status musi pochodzić z workflow tego projektu.
• Zmiana statusu jest spójna w szczegółach, Kanbanie, dashboardzie i raportach.
• Termin końcowy nie powinien poprzedzać daty rozpoczęcia.
• Raporty wynikają z aktualnych danych źródłowych, a operacje administracyjne są chronione serwerowo.

Kryteria funkcjonalne

Uprawniony użytkownik może się zalogować, utworzyć projekt i zadanie, przypisać członka, zmienić status, zobaczyć spójny wynik w Kanbanie, dashboardzie i szczegółach, znaleźć termin w kalendarzu oraz utracić prawo edycji po obniżeniu roli.

Role użytkowników

Model uprawnień

Role są hierarchiczne i oparte na zapisanej macierzy uprawnień. Dostęp do operacji zależy jednocześnie od poziomu roli i członkostwa w projekcie. Liczba uprawnień odzwierciedla badaną bazę, lecz nie zastępuje testu poszczególnych operacji.

Zasady dostępu

• Stosować najmniejsze niezbędne uprawnienia.
• Chronić operacje na serwerze; ukrycie elementu UI nie wystarcza.
• Nie tworzyć więcej niż jednego logicznego członkostwa użytkownik-projekt.
• Testować zmianę roli w istniejącej i nowej sesji.
• Chronić ostatnie konto Owner przed odebraniem kontroli nad instancją.

Przypadki użycia

Scenariusze testowe

Organizacja testów

Testy należy wykonywać na odtworzonej instancji, używając kont Owner, Editor, Commenter i Read Only oraz projektu TEST-Project. Dla każdego przebiegu należy zachować czas, rolę, wynik HTTP/UI, identyfikatory obiektów i wycinek logu.

Macierz odbioru

Ograniczenia i założenia

Ograniczenia badania

• Nie wykonywano destrukcyjnego resetu, pełnego testu UI w przeglądarce ani testu obciążeniowego.
• Integracje z pocztą, LDAP/OIDC i usługami zewnętrznymi nie były skonfigurowane.
• Zakres modułów może zależeć od licencji lub wtyczek; wolumen wtyczek był pusty.
• Stan demonstracyjny nie pokrywa raportowania czasu, klientów, sprintów ani współpracy wieloosobowej.

Ograniczenia rozwiązania

• Jednowęzłowy stack nie zapewnia wysokiej dostępności.
• HTTP bez TLS jest odpowiedni tylko dla środowiska lokalnego.
• Jakość raportów zależy od kompletności statusów, dat, estymat i timesheetów.
• Funkcje powiadomień i integracji zależą od zewnętrznej konfiguracji.

Założenia funkcjonalne

• Organizacja posiada co najmniej jednego Ownera.
• Użytkownicy otrzymują dostęp wyłącznie do potrzebnych projektów.
• Zespół ustala znaczenie statusów i definicję zakończenia pracy.
• Dane demonstracyjne nie trafiają do produkcji bez jawnej decyzji.
• Testy odbiorowe używają osobnych kont dla każdej roli.

Ryzyka i zalecenia

Case Study

Kontekst eksperymentu

Eksperyment miał wykazać, czy system bez wcześniejszej dokumentacji może zostać opisany na tyle precyzyjnie, aby niezależny Agent AI odtworzył go bez dostępu do aktywnych kontenerów, wolumenów i prywatnych sekretów.

Przebieg

1. DevOps uruchomił środowisko

Przygotowano .env i Compose, uruchomiono MySQL z trwałym wolumenem i healthcheckiem, a następnie Leantime z czterema wolumenami oraz portem 8080. Wynikiem był sprawny, ale nieudokumentowany stack.

2. Agent AI przeprowadził discovery

Agent zinwentaryzował deklarację i runtime, obrazy, digesty, procesy, sieć, porty, wolumeny, logi, bazę, CLI oraz zachowanie HTTP. Porównanie różnych dowodów ujawniło telemetrię, strefę czasu, stare wolumeny, duplikat członkostwa i niedokładność statystyk InnoDB.

3. Agent AI wykonał inżynierię odwrotną

Konfiguracja i runtime dały architekturę, schema i dane dały model informacji, a moduły obrazu i działające UI dały funkcje biznesowe. Oddzielono produkt, konfigurację wdrożenia oraz dane demonstracyjne.

4. Powstał Projekt Funkcjonalny i testy

PF definiuje oczekiwane zachowanie bez narzucania implementacji. Przypadki użycia i 18 testów tworzą sprawdzalny kontrakt obejmujący funkcje, autoryzację, spójność widoków, trwałość i operacje.

5. Dokumentacja zasila niezależną rekonstrukcję

Drugi Agent AI powinien przygotować Compose, wygenerować sekrety, uruchomić bazę i aplikację w poprawnej kolejności, wykonać migracje i seed, a następnie przeprowadzić cały odbiór. Nie może korzystać z aktywnych wolumenów ani zgadywać obecnych haseł.

Mierniki sukcesu

• Brak zależności od wolumenów źródłowych i prywatnego .env.
• Zgodność architektury, wersji, granic sieci i modelu danych.
• Spełnienie PF oraz wszystkich krytycznych scenariuszy.
• Trwałość po restarcie i odtwarzalny backup/restore.
• Jawne rozróżnienie produktu, konfiguracji, seedu i anomalii.

Wnioski

Ocena środowiska

Badany stack jest niewielki, logicznie spójny i poprawnie izoluje bazę od hosta. Healthchecki i nazwane wolumeny zapewniają właściwą kolejność startu oraz podstawową trwałość. Aplikacja 3.9.5 działa w zweryfikowanej ścieżce logowania i dashboardu.

Warunki wiarygodnej rekonstrukcji

Wiarygodna rekonstrukcja wymaga zamrożenia artefaktów binarnych, nowych sekretów, kontrolowanego sposobu inicjalizacji, zgodnego modelu ról, dokładnych liczników oraz testów przekrojowych. Zalecanym wariantem jest czysta instancja z jawnym seedem, ponieważ usuwa historyczne anomalie i pozwala rozróżnić dane systemowe od demonstracyjnych.

Priorytety przed użyciem produkcyjnym

1. Przypiąć digesty i ustanowić procedurę aktualizacji z backupem.
2. Przenieść sekrety do chronionego mechanizmu i włączyć TLS.
3. Uzgodnić strefę czasu, locale i politykę telemetrii.
4. Usunąć duplikat członkostwa i ujednolicić nagłówki bezpieczeństwa.
5. Przeprowadzić testy ról, trwałości i restore oraz monitorować deprecacje.

Metryka dokumentu

Koniec dokumentu. Raport nie zawiera haseł, kluczy sesyjnych ani innych wartości tajnych odczytanych ze środowiska.