Automatyzacja tablic

Automatyzacja tablic

Raporty zmian

W zakładce Raporty wybierz daty od–do lub Ostatnie 7 dni (dzisiaj i sześć poprzednich dni). Obie daty są wliczone zgodnie ze strefą czasową przeglądarki. Właściciel, edytor i przeglądający widzą liczniki oraz chronologiczną listę zmian, wartości przed/po i autora, jeśli jest znany. Strona zawiera 30 wpisów. Historia pozostaje po usunięciu zadania; odnośniki otwierają istniejące, niearchiwalne zadania. Pełna historia edycji zaczyna się od wdrożenia raportów. Wcześniejsze okresy zawierają tylko zachowane zdarzenia automatyzacji i review, o czym informuje komunikat.

Archiwum zadań

Wybierz Archiwum, aby przeglądać zadania ukryte na tablicy. Wyszukuj po tytule i opisie, filtruj według kolumny i kategorii; wyniki są stronicowane od ostatnio zarchiwizowanych. Wybór tytułu otwiera treść i historię pracy agenta.

Właściciel i edytor mogą archiwizować pojedyncze zadanie w szczegółach (sekcja dodatkowych opcji) lub wszystkie zadania kolumny przyciskiem Archiwizuj zadania. Potwierdzenie pokazuje liczbę wszystkich zadań kolumny, niezależnie od filtrów tablicy. Jeśli choć jedno ma pracę w kolejce, w toku lub oczekującą na odpowiedź, cała operacja jest blokowana. Najpierw zakończ lub anuluj tę pracę.

Przywróć umieszcza zadanie na końcu pierwotnej kolumny bez uruchamiania agenta. Archiwizacja zachowuje treść, identyfikator i historię. Zadania archiwalne nie podlegają edycji ani przesuwaniu. Obserwator może przeglądać archiwum. Kolumny z archiwalnymi zadaniami nadal nie można usunąć.

Projekty, backlog i sprinty

Dotychczasowe tablice są projektami z widokami Tablica, Backlog i Zarządzanie. Właściciel dodaje istniejące konto przez e-mail i ustawia niezależnie dostęp do tablicy i backlogu: Brak dostępu, Odczyt, Edycja. Właściciel ma pełne prawa. Dostęp do backlogu obejmuje wszystkie jego zadania. Sam backlog nie daje dostępu do tablicy, archiwum, raportów, rozmów AI ani zdarzeń tablicy.

Backlog pokazuje pozycje jako małe kafle: tytuł, kolorowy stan, postęp (np. 2/3 wykonane), sprint i datę wykonania lub dodania. Kolory odpowiadają stanom zadań na tablicy: zielony – wykonane, niebieski – zaplanowane, turkusowy – w trakcie, fioletowy – review lub decyzja ręczna, bursztynowy – oczekiwanie, czerwony – błąd, szary – do zrobienia lub brak zadań. Kliknięcie kafla otwiera szczegóły (adres z parametrem item): opis, tagi, autora, historię i listę przypiętych zadań z ich stanem, kolumną, sprintem i datą wykonania.

W backlogu tworzysz i edytujesz tytuł, opis oraz tagi. Pozycja nie ma kolumny, nie uruchamia automatyzacji i zostaje w backlogu także w trakcie i po wykonaniu zadań. Utwórz zadanie na tablicy wymaga edycji obu obszarów: wybierz kolumnę i opcjonalny tag sprintu, domyślnie bieżącego. Powstaje nowe zadanie z tytułem, opisem i tagami pozycji, przypięte do niej; automatyzacja może ruszyć po wejściu do skonfigurowanej kolumny. Do jednej pozycji można przypiąć kilka zadań: utworzyć kolejne albo Przypnij istniejące zadanie z tablicy, a przypięte zadanie Odepnij. Zadanie jest wykonane w skonfigurowanej kolumnie Wykonane lub kolejce scalania albo po archiwizacji; na tablicy bez tych etapów – w ostatniej kolumnie. Data wykonania to pierwsze wejście w ten stan. Osoba z samym dostępem do backlogu widzi stan, kolumnę, sprint i daty przypiętych zadań, ale nie ich tytuły ani treść. Usuń po potwierdzeniu kasuje pozycję razem z historią, a przypięte zadania zostają na tablicy; wymaga edycji backlogu i nie można tego cofnąć.

W Zarządzaniu ustaw tag bieżącego sprintu lub wyczyść pole. Domyślnie pole jest puste. Na tablicy filtr Sprint domyślnie używa bieżącego tagu, pozwala też wybrać inny tag lub Wszystkie sprinty. Jawny parametr adresu sprint ma pierwszeństwo (sprint= wyłącza filtr). Wyszukiwanie i pozostałe filtry działają łącznie. Zmiana bieżącego sprintu nie zmienia tagów zadań.

Migracja zachowuje identyfikatory projektów oraz istniejące zadania klienta na tablicy wraz z oryginalną treścią i historią. Dawny klient otrzymuje edycję backlogu bez dostępu do tablicy. Lista backlogu pod /app/boards/:id/requests odświeża się co 10 sekund; konflikty rewizji nie nadpisują zmian innej osoby.

Pozycje backlogu można niezależnie oznaczać jako do zrobienia lub zrobione i filtrować według tego znacznika. Widok listy pozwala ustalać wspólną kolejność przez przeciąganie lub przyciski strzałek. Każda pozycja ma dyskusję: osoby z dostępem do odczytu mogą czytać, a z prawem zapisu także wysyłać wiadomości. Autor może usunąć własną wiadomość, a właściciel projektu dowolną.

Od pomysłu do wyniku

*Widoczny postęp pomaga wybrać następny krok.*

Zapisz pomysł, wróć do niego z zespołem i wybierz to, co teraz przyniesie największą wartość.

Mała poprawka, jasny cel

Formularz odrzuca adres e-mail, ale użytkownik nie wie dlaczego? Dodaj zadanie „Popraw walidację formularza”. Opisz oczekiwany efekt: jasny komunikat przy polu oraz zachowanie wpisanych danych. Konkretny problem ułatwia przygotowanie planu.

*Cel poprawki pozostaje blisko rozmowy i dalszej pracy.*

Rozmawiaj, doprecyzuj, zdecyduj

Dodaj szczegóły w rozmowie z AI: „Komunikat powinien pojawić się przy polu e-mail”. Odpowiedz na pytania i sprawdź proponowany plan. Rozwijasz kontekst w tym samym zadaniu. AI pomaga przygotować propozycję działania; Ty oceniasz zakres i rezultat. Dzięki temu więcej uwagi zostaje na to, czy rozwiązanie pomaga użytkownikowi.

*Zrzuty przedstawiają dane demonstracyjne w rzeczywistym panelu.*

Uruchom pracę i przejrzyj rezultat

Skonfiguruj projekt i kolumny automatyzacji. Uruchom workera AI poleceniem goat worker:ai:run. Przenieś zadanie do planowania, doprecyzuj plan w rozmowie, a następnie go przejrzyj. Przeniesienie do kolumny wykonania (Execution) zatwierdza zakres i uruchamia realizację. Sprawdź rezultat i testy.

Automatyczny przegląd może zlecić poprawki; trzecie odrzucenie wymaga decyzji człowieka. Tryb w pełni automatyczny uruchamia nowo ukończone plany bez dodatkowego przeniesienia zatwierdzającego. Wznowienie zachowuje zatwierdzony plan i checkout; już przejęte wykonanie wraca do pierwotnego workera. Osobny worker CI/CD wykonuje testy i wdrożenie po zgodnym merge pull requesta, a nie po zwykłym pushu. Właściciel projektu konfiguruje go, kopiuje jednorazowy sekret webhooka oraz śledzi historię przebiegów w karcie CI/CD projektu.

Przed aktualizacją

Przed aktualizacją serwera i workerów zastosuj migracje child: 1017 dodaje przegląd, 1018 wznowienie, 1019 automatyczne wykonanie planu, a 1020 CI/CD. Szczegóły w repozytorium: child/app/boards/README.md, WORKERS.md i CICD.md.

Worker CI loguje się przez goat login i obsługuje wszystkie projekty właściciela z włączonym CI/CD. Projekt nie wymaga UUID ani tokena workera; zachowuje własną gałąź, skrypty, webhook i sekrety. Najpierw wdróż migrację child 1032 i backend, następnie panel i nowe CLI.

Tagi i filtrowanie

Dodaj tag w szczegółach zadania, wpisując nazwę i naciskając Enter lub wybierając podpowiedź. Zapis uwzględnia również poprawny, jeszcze niezatwierdzony wpis. Zadanie może mieć do 20 tagów po 64 znaki. Karta pokazuje trzy tagi; przycisk +N odsłania pozostałe.

Filtr tagów otwiera listę z wyszukiwaniem i checkboxami. Pokazuje zadania z dowolnym wybranym tagiem, jednocześnie uwzględniając tekst, stan i kategorię. Aktywne filtry można usuwać pojedynczo. Są zapisane w adresie, więc działają po odświeżeniu, udostępnieniu linku i użyciu Wstecz. Na telefonie dodatkowe pola rozwija przycisk Filtry. Archiwum znajdziesz w menu tablicy, a archiwizację kolumny w jej menu operacji.

Polecenia agenta i zestawy zmian

Worker udostępnia goat_run_command niezależnie od Bash agenta.
Generowanie: {"command":"re","args":[]}. Uruchomienie recepty:
{"command":"run:script","args":["--path=@goatcms/herd/test.goat"]}.
goat_run_script pozostaje skrótem, a run:docker uruchamia polecenia w kontenerze.
Błąd uprawnień Bash nie oznacza braku dostępu do skryptów Goat. Agent powinien
użyć udostępnionego narzędzia i podać rzeczywiste polecenie, kod zakończenia i błąd.
Planowanie i review pozwalają tylko na odczyt; worker generuje źródła przed nimi.

Właściciel dodaje edytowalne moduły w ustawieniach automatyzacji, podając tylko nazwę:
panel odczytuje repozytorium i gałąź z pliku herd/_modules.goat projektu i sprawdza
deklarację, serwer Git, prawo zapisu z profilem Git właściciela oraz gałąź, pokazując
wynik każdej kontroli. Edytować można tylko moduły śledzące gałąź Git. Agent otrzymuje
alias, ścieżkę, gałąź i tryb dostępu każdego modułu. Edytuje tylko dozwolone moduły;
goatapp/ odświeża wyłącznie generator. Cykl pracy łączy gałęzie projektu i modułów,
a kolejne zadania korzystają z wcześniejszych zmian. Worker publikuje PR-y i kieruje
zmiany ze wszystkich repozytoriów do review.

Dashboard i zakładka Wykonanie pokazują zestawy zmian. Ich wykonawca zatwierdza
„Scal cały zestaw” po sprawdzeniu wszystkich PR-ów. Najpierw scalane są moduły,
na końcu projekt. Częściowy sukces pozostaje zapisany i wstrzymuje zwykłą kolejkę;
ponowienie uzgadnia wynik, a zadanie naprawcze poprawia niescalone repozytoria.
Nowy cykl zaczyna się po pełnym scaleniu. Aktualizuj serwer i panel przed workerem.
Przykłady i kontrakt API opisuje przewodnik agenta oraz dokumentacja workerów w repozytorium.

Kolejka scalania

Nowe tablice mają kolumnę Kolejka scalania między Review a Wykonanymi; na
pozostałych wybierz ją w ustawieniach automatyzacji. Zaakceptowane zadania czekają
tam i po kolei, w kolejności, trafiają na gałąź roboczą zestawu zmian; karta pokazuje
swoją pozycję. Scalona karta przechodzi do Wykonanych, a gałąź zadania jest usuwana.
Jeśli zadanie wymaga dalszej pracy, przeniesienie go z powrotem do Wykonania tworzy
nową gałąź zadania z gałęzi roboczej. Konflikty najpierw rozwiązuje git, korzystając
z rozwiązań zapisanych przy wcześniejszych zadaniach; agent rozwiązuje tylko resztę.
Konflikt, którego nie da się rozwiązać, zostawia kartę w kolejce z przyciskiem
Ponów integrację i nie wstrzymuje kolejnych kart. Karta przeniesiona ręcznie do
Wykonanych czeka w kolejce, aż zostanie zintegrowana. Przed scaleniem zestawu zmian
gałąź robocza, która nie ma najnowszych zmian gałęzi docelowej, otrzymuje je zwykłym
merge'em gita; jeśli wystąpi konflikt, rozwiązuje go zadanie konfliktowe. Scalone
gałęzie robocze są usuwane, a kolejny cykl tworzy nową.

Po awarii workera

Po utracie heartbeat zadanie jest oznaczane jako przerwane po wygaśnięciu dzierżawy (45 sekund; kontrola co 10 sekund). Review wraca automatycznie do kolejki; po trzech nieudanych próbach wymaga decyzji człowieka. Wykonanie zachowuje lokalne pliki i wymaga uruchomienia pierwotnego workera przed użyciem Wznów. Niedostępny worker nie zatrzymuje późniejszych zadań, które może przejąć inny worker. Wcześniejsze niezapisane zmiany nadal wymagają rozliczenia przed scaleniem zestawu.

Worker zapisuje prywatny dziennik publikacji przed zmianą HEAD, dzięki czemu może odzyskać własny commit po przerwaniu zapisu stanu lub pushu. Nie usuwa lokalnych plików ani nie akceptuje obcych commitów. Utrata komputera lub dysku wymaga odtworzenia nieopublikowanych plików z kopii zapasowej. Ręcznie anulowane zadania nie są automatycznie ponawiane.

Kontynuacja po wyczerpaniu limitu agenta

Wybór Automatycznie pozwala kontynuować planowanie i wykonanie u innego dostępnego agenta: Claude → Codex lub Codex → Claude, także na innym workerze tego samego użytkownika. Ręczny wybór agenta przypina te dwa etapy. Review pozostaje niezależne, preferuje innego agenta niż wykonawca i może przełączać się po wyczerpaniu limitu.

Worker zachowuje zatwierdzony plan, historię i postęp. Przejęcie na innym komputerze wymaga zapisania oraz opublikowania zmian we wszystkich edytowalnych repozytoriach. Jeśli push się nie powiedzie, pozostaną duże pominięte pliki lub niezakończony merge, kontynuacja czeka na pierwotnego workera, bez usuwania lokalnych zmian. Gdy oba limity są wyczerpane, zadanie czeka w kolejce bez zajmowania aktywnego toru i wznawia się automatycznie. Historia pokazuje przekazanie oraz agenta i workera kontynuującego pracę.

Najpierw wdroż migrację 1029 i serwer, następnie zaktualizuj CLI oraz panel. Starsze workery zachowują oczekiwanie na odnowienie limitu i nie przejmują nowych kontynuacji.

Wyłączanie Codexa lub Claude

Aby zachować tokeny na inne projekty, właściciel projektu może niezależnie przełączyć Codex włączony i Claude włączony w sekcji Agenci AI ustawień projektu. Domyślnie obaj są włączeni. Trwająca praca się dokończy; potem wyłączony agent nie podejmuje w tym projekcie nowych planów, wykonań, przeglądów ani wznowień, a inne projekty działają bez zmian. Zadania i przeglądy w trybie Automatycznie trafiają do włączonego agenta; zadania przypisane do wyłączonego agenta czekają w kolejce z przyczyną widoczną na karcie i w kolejce, a po ponownym włączeniu są kontynuowane. Gdy obaj agenci są wyłączeni, praca AI w projekcie wstrzymuje się, ale skrypty nadal działają. Przełączenie nie unieważnia przygotowanych planów. Przed wdrożeniem backendu i panelu zastosuj migrację child 1036.

Wybór modelu i effort

W sekcji Modele i effort ustawień projektu właściciel ustawia model i effort (poziom rozumowania) osobno dla Codexa i dla Claude. We właściwościach zadania każdy członek, który może edytować tablicę, może je nadpisać dla jednego zadania. Każde pole dziedziczy się osobno: wartość zadania, a gdy jej brak — wartość tablicy, a gdy i tej brak — domyślne ustawienia agenta na workerze. Zadanie może więc podnieść tylko effort, a model nadal pochodzi z tablicy. Opcja Dziedzicz z tablicy w zadaniu i Domyślne agenta na tablicy czyszczą pole.

Codex przyjmuje effort: brak, minimalny, niski, średni, wysoki i bardzo wysoki; Claude: niski, średni, wysoki, bardzo wysoki i maksymalny. Model to nazwa przyjmowana przez CLI agenta, np. gpt-5-codex lub opus. Konfiguracja jest ustalana przy rozpoczęciu uruchomienia i widoczna obok agenta w historii uruchomień: trwająca próba ją zachowuje, a kolejny plan, wykonanie, review lub wznowienie używa bieżących ustawień. Zmiany nie unieważniają przygotowanych planów. Jeśli agent nie może wystartować z wybranym modelem lub effort, uruchomienie kończy się błędem wskazującym to ustawienie. Przed korzystaniem z tych ustawień zastosuj migrację child 1040 i zaktualizuj workera; starsze workery je pomijają.

Obserwowanie scalania zestawu zmian

Zakładka Wykonanie pokazuje bieżący etap scalania, kolejność repozytoriów,
liczbę scalonych repozytoriów, ostatnią aktywność i termin kolejnej próby. Sekcja
Co blokuje scalenie wskazuje PR, kontrolę Git lub zadanie wymagające uwagi,
wraz z odnośnikiem i zalecanym działaniem. Pulpit pokazuje to samo podsumowanie.

Rozwiń Historia i logi scalania, aby zobaczyć czasy, wyniki i szczegóły
techniczne operacji. Starsze zdarzenia można doładować bez utraty widoku.
Historia zaczyna się od pierwszej próby po wdrożeniu funkcji; wcześniejsze logi
nie są odtwarzane. Zapisy przetrwają restart serwera i nie zawierają tokenów Git
ani surowych odpowiedzi serwera Git.

Serwer sprawdza warunki oczekiwania co 20 sekund. Przejściowe błędy Git ponawia
po 20, 40, 80, 160, a następnie maksymalnie 300 sekundach. Ponów teraz zleca
wcześniejszą kontrolę bez dublowania aktywnej operacji. Konflikty rozwiązuje
powiązane zadanie naprawcze; wymagane review i nieudane kontrole są widoczne do
czasu usunięcia przyczyny. Brak potwierdzonej aktywności oznacza wygasłą próbę
lub zaległą kontrolę. Osobny komunikat o braku połączenia z API oznacza, że panel
nie może odświeżyć danych.

Przed wdrożeniem nowego backendu i panelu zastosuj migrację child 1033.

Artefakty testów i przeglądarka agenta

W historii zadania dostępne są screenshoty, raporty i ślady z testów E2E oraz sesji przeglądarki. Pozostają bezterminowo, także po wznowieniu pracy na innym workerze. Archiwizacja ich nie usuwa; usunięcie zadania usuwa również jego artefakty. Raporty HTML i archiwa pobiera się jako pliki. Brak miejsca lub przekroczenie limitu jest zgłaszane oddzielnie od wyniku testu.

Opcjonalna przeglądarka jest uruchamiana na żądanie agenta podczas wykonania, w jednorazowym środowisku z testową aplikacją i świeżym profilem. Nie korzysta z kont ani haseł użytkownika. Domyślnie widzi wyłącznie aplikację zadania. Dostęp do publicznych stron wymaga zgody właściciela w ustawieniach projektu i włączenia go dla zadania przez osobę uprawnioną do jego wykonania. Agent może poprosić o tę zgodę; należy użyć dedykowanych przycisków zezwolenia lub odmowy. Zwykła odpowiedź tekstowa nie zmienia uprawnień. Zgoda pozostaje przy zadaniu po wznowieniu, ale wyłączenie jej w projekcie blokuje dostęp. Host, sieć lokalna i usługi metadata pozostają niedostępne.

Przed wdrożeniem backendu i panelu zastosuj migrację child 1034 i przygotuj trwały magazyn artefaktów; przeglądarkę włączaj na workerze dopiero potem. Workery bez przeglądarki działają bez zmian.

Załączniki zadań i backlogu

Do zadań i pozycji backlogu można dodawać pliki, np. logo, CSV lub arkusze Excel. W szczegółach dostępne są pobieranie i usuwanie; podczas tworzenia zadania lub przypinania go do backlogu wybierz pliki do skopiowania. Kopie są niezależne od oryginałów. Domyślny limit to 50 MB na plik i 50 plików na zadanie. Agent otrzymuje pliki w .goat/attachments/{id}/{name} przed planowaniem, wykonaniem i review, a ich lista znajduje się w prompcie. Pliki z tego katalogu nie trafiają do commita; agent może skopiować potrzebne zasoby do repozytorium.