Dla programistów · maszyna stojąca za hasłem „vibe the project”
Każdy projekt w aplikacji Motir przechodzi przez ten sam instrument. Moduły to Motir i jego agenci. Pokrętła i przełączniki należą do Ciebie: nic nie idzie dalej, dopóki człowiek ich nie przestawi.
Motir i agenciTwoja decyzja
Przewiń rysunek w bok →
Każdy moduł z powyższego rysunku z bliska. Najedź na jeden, by znaleźć go na rysunku.
[01] Planowanie z AI
Zacznij od zdania, repozytorium albo importu z Jira, Linear lub Plane. Planer czyta to, co istnieje, w tym graf kodu Twoich repozytoriów, i zadaje pytania uzupełniające tam, gdzie prośba jest niejednoznaczna.
Przygotowuje epiki, historie, zadania i podzadania — każde z typem, wykonawcą, rozmiarem i krawędziami blocked_by. validate_plan sprawdza drzewo, zanim je zobaczysz.
[02] Ty · bramka planu
Nic nie trafia na tablicę, dopóki człowiek nie zatwierdzi planu. Proś o zmiany zwykłymi słowami; każda runda to nowa tura, a historia planu zachowuje każdą wersję i powód zmiany.
[03] Elementy robocze
Zatwierdzony plan staje się elementami roboczymi ze sprintami, backlogiem i roadmapą. Wykonawcą każdego elementu roboczego jest agent lub human.
Przez zadania ręczne (konto, sekret, rekord DNS, akceptacja wydania) motir guide prowadzi krok po kroku.
[04] Uruchomienie agenta
Agent bierze kolejny gotowy element roboczy (motir next lub motir run <KEY>), rezerwuje go, buduje na własnej gałęzi i otwiera jeden pull request na repozytorium, powiązany z elementem roboczym.
Błąd znaleziony poza własnym elementem roboczym nie zatrzymuje uruchomienia: agent ustala jego przyczynę, zapisuje go poleceniem motir log bug w folderze Błędy jako osobny element roboczy i pracuje dalej.
Każde uruchomienie zapisuje środowisko agenta, model, każdy krok i wynik. Agenci łączą się przez MCP — na Twojej maszynie albo jako hostowani agenci Motir.
[05] Ty · bramka scalania
Element roboczy przechodzi do Implemented, a agent publikuje instrukcję testowania. Historie dostają wideo akceptacyjne nagrane w CI. Przeglądasz, zatwierdzasz i scalasz; scalenie zamyka element roboczy. Nic nie trafia do Done bez człowieka.
[06] Naprawa
Czerwony lub konfliktowy pull request jest naprawiany na własnej gałęzi poleceniem motir fix, w maksymalnie pięciu próbach. Przerwane uruchomienie (zamknięty laptop, utracona piaskownica) jest wznawiane poleceniem motir continue na gałęzi, którą zostawiło.
Błędy zapisane po drodze czekają w folderze Błędy; motir fix bugs przerabia je po kolei, od najstarszego.
[07] Pętla uczenia
Agent, który nie może zbudować elementu roboczego, najpierw sprawdza, czy to nadal to, co zatwierdzono w planie (get_approved_shape_verdict), żeby późniejszej edycji nie zrzucić na planer. Jeśli plan był błędny, zostaje zaplanowany ponownie, a zmiana jest zapisywana wraz z powodem.
Pomyłka staje się lekcją albo wzmacnia istniejącą; jeśli żadna reguła jej nie obejmuje, zapisywany jest błąd planowania. Kolejny plan najpierw czyta lekcje. Lekcje, które nie powracają przez 90 dni, przechodzą na emeryturę.
[08] Pamięć
Projekty graficzne, strony decyzji, dokumentacja, lekcje, rewizje planu i historia każdego uruchomienia są przy elementach roboczych. Każdy — od Ciebie, przez nową osobę w zespole, po kolejnego agenta — może podjąć projekt po miesiącach, bez niczyich wyjaśnień.
Rdzeń do zarządzania projektami jest open source na licencji GPL-3.0. Hostuj go samodzielnie albo korzystaj z niego na motir.co.