Panel Developera

Plany zmian w samym Developerze, omówione w Rozmowie (/a-omawianie-koncepcji, potem /a-plan-developera). „Realizuj” otwiera rozmowę z Claude'em, który zrobi MR, scali, wdroży i oznaczy problem jako wdrożony.

Zatrzymania automatu i wezwania architekta oraz ich naprawy. Każde nowe zatrzymanie i wezwanie automat porównuje z tą listą: jeśli było już naprawiane, w dzienniku pracy stoi „POWTÓRKA PO NAPRAWIE”.

Zgłoszenia nadzorcy do orchestratora Kowalewskiego (issue orchestrator-feedback) i stan każdego: co stoi, dlaczego, kto ma ruch i od kiedy.

Czas pracy agentów per przedział i model oraz liczba scalonych MR-ów według zapisanego czasu scalenia. Czasy obejmują wyłącznie zakończone uruchomienia; odcinki sprzed zapisu modelu widnieją jako „nieznany".

Skuteczność per MR — ostatnie 100 prac

Powroty: wejścia wykonawcy po pierwszym. Pierwszy odbiór: pierwszy zakończony review z wynikiem. Bez postępu: czas od ostatniego wyniku pracy lub kontroli, także podczas trwającej pracy; nie oznacza automatycznie awarii. Postój: czas od zakończenia procesu do wznowienia tego MR-a. Środowisko: przybliżone przerwy między uruchomieniami systemu według dziennika; mogą pokrywać się z postojem. Brak danych: —. Te czasy nie sumują się.

Reguły z wykrytych błędów. Do agentów trafiają tylko reguły aktywne i sprawdzone przez bramkę. Recenzent i audytorzy dostają tylko reguły z obszaru ocenianych plików.

Zaznaczone pójdą jako jedno zadanie. Audytor najpierw sprawdzi aktualny kod i zdecyduje, czy do pozostałej pracy potrzebny jest planista.