Proces pracy#

Ta strona opisuje, jak w projekcie powstaje zmiana: gdzie żyje plan, jak wygląda praca agenta i jak dokumentacja trzyma się razem z kodem.

Planer i zgłoszenia#

Planowanie jest w panelu staff — to widok i sterowanie właściciela projektu, a nie osobne narzędzie do wymiany zadań. Karta ma tytuł, notatkę, kolumnę i termin; notatki (tekstowe i głosowe) leżą pod kanbanem i są wspólne dla całego staffu.

Do 2026-09-21 karty planera synchronizowały się w obie strony ze zgłoszeniami w repozytorium: zmiana kolumny ustawiała etykiety zgłoszenia, zamknięcie zgłoszenia przenosiło kartę, a usunięcie karty kasowało zgłoszenie. Decyzją właściciela mostek został zdjęty — planowanie jest dziś w całości lokalne (karta zmienia stan tylko w panelu), a panel nie pokazuje numerów zgłoszeń ani etykiet repozytorium. Kolumny i etykiety z czasów integracji zostały w danych jako zapis historyczny.

Drugi filar to repozytorium po stronie zewnętrznej: trzyma kod, znaczniki wersji i historię, ale nie jest miejscem publikowania ani budowania (Wydania APK). Zmiany są wypychane automatycznie, żeby kod poza serwerem był w pełni aktualny, a nie „w połowie drogi”.

Kolumny i etykiety#

Kolumny kanbanu i ich znaczenie:

Z czasów integracji z repozytorium zostały jeszcze nazwy etykiet, które nadal opisują obszar zadania: apka, www, api, infra, treść. Używa się ich w opisach zadań, żeby od razu było widać, której części projektu dotyczy praca — i żeby dało się to sprawdzić przed wypchnięciem zmian (na przykład zadanie w obszarze „www” uruchamia kontrole strony).

Co robi agent#

Praca nad paczką zmian ma stałą procedurę — to nie „agent zrobi, co uważa”, a umowa z jasnym zakresem:

1. Każda paczka ma umowę zadania w repozytorium: co ma powstać, jakimi plikami wolno się zajmować, czego nie ruszać i co jest dowodem wykonania.
2. Zakres plików jest rozdzielony między zadania. Dwóch wykonawców nie pisze tego samego pliku, a plików wspólnych (menu, spis funkcji, generator) nie zmienia nikt poza zadaniem, które je posiada.
3. Zadanie ma kolejność: najpierw fundament (generator i bramka), potem treść, na końcu wdrożenie. Równoległe zadania nie czekają na siebie, jeśli nie dzielą plików.
4. Wykonawca dowodzi wyniku: liczba plików, wynik bramki z dosłownym wypisem, kod odpowiedzi strony, liczba kadrów. Brak dowodu to nie „zrobione”, a „do sprawdzenia”.
5. Po zakończeniu pracy nikt nie zamyka zadania sam sobie: zmianę sprawdza osobne zadanie weryfikacji, ze świeżym kontekstem, próbując zaczerwienić bramki i podważyć twierdzenia.
6. Karta w planerze wraca do właściciela w kolumnie „do odbioru” — dopiero jego decyzja zamyka temat.

Dwie rzeczy są twardymi zakazami: nie budujemy i nie wydajemy aplikacji bez osobnej decyzji o wydaniu, oraz nie zmieniamy ustawień produkcyjnych po cichu — każda zmiana na serwerze ma swoje miejsce w umowie zadania i w dzienniku.

Dokumentacja i mózg projektu#

Wiedza o projekcie żyje w trzech warstwach i wszystkie trzy są w repozytorium:

Zasady, które trzymają dokumentację aktualną:

• Zmiana funkcji i zmiana opisu idą razem, w jednym zestawieniu zmian. Nie ma etapu „dopisze się później”.
• Spis treści i spis funkcji są danymi (pliki nav.json i features.json): z jednego powstaje menu boczne, z drugiego wiadomo, co jest opisane i gdzie. Dodanie strony bez wpisu w spisie to błąd, który bramka zgłasza jako stronę-sierotę.
• Kotwice sekcji są identyczne w obu językach, więc link do sekcji działa tak samo po polsku i po angielsku; wersją źródłową jest polska.
• Bramka dokumentacji pilnuje struktury, odsyłaczy, obrazów i tego, że każda opcja z ekranu Ustawień ma swój opis (Jakość i kontrole).

Opis zgodny z aplikacją 0.120.1 (zaktualizowano 2026-09-26).