Gitive zarządza DigitalTwin: prywatnym pulpitem Linux/noVNC, środowiskami projektów, kopiami plików, dostępem GitHub i ticketami Planfile. Etap P0 pozwala utworzyć pełną prywatną kopię wybranego projektu i jego runtime Python/Node oraz wykonać testy we własnym kontenerze. Wykonawczy DAG i podłączenie trzech silników do tego kontenera pozostają następnym etapem.
Panel WWW: http://127.0.0.1:8793/ — karty projektów, tablica ticketów,
środowiska, testy i terminal noVNC. Ctrl+K wyszukuje projekt lub zadanie.
Instrukcja panelu i kolejki hosta.
./gitive menu 4 # wybierz projekt → jego menu
./gitive project new # dodaj repo z listy folderów ~/github
./gitive project open doctor-agent # tickety, uruchamianie, procesy, wyniki
./gitive project status doctor-agent
./gitive twin terminal doctor-agent # noVNC: tom + oryginalna ścieżka + runtime projektu
./gitive tickets show doctor-agent # wybór ticketu z listy./gitive shell zachowuje kontekst username/project/ticket/operation>, np.
tom/doctor-agent/PLF-001/idle>. Wybierz projects, numer projektu, tickets
i numer ticketu. status, run, sync pull, sync push oraz operations
działają na wybranym tickecie. new tworzy ticket, back (lub 0) wraca
poziom wyżej, exit kończy shell. W Bash używaj ./gitive menu NUMER.
Operacja odświeża się co sekundę w terminalu: planning, coding, tests,
commit, merge lub idle. operations pokazuje także funkcje i czasy
krótkich etapów. merge w lokalnym wykonawcy oznacza lokalny fast-forward,
nie połączenie PR na GitHub. Obsługa shellu i pochodzenie ticketów.
Architektura i obsługa DigitalTwin · Plan rozwoju i znalezione integracje VS Code/KVM.
Gitive łączy benchmark trzech rozwiązań do naprawy kodu, panel WWW, CLI i istniejący pulpit noVNC z ekosystemu Subactor. Pozwala dodawać projekty do developmentu, wybierać rozwiązanie według benchmarku oraz tworzyć prywatne kopie projektów i profili z PC.
Kod aplikacji znajduje się w src/gitive/. Silniki glm53, gpt6 i opus5 pozostają osobnymi komponentami repozytorium. Ich nazwy identyfikują implementacje — model wywoływany przez LLM określa konfiguracja .env.
Gitive jest zarządcą workspace, projektów i procesów. Workspace opisuje środowisko (kontener, runtime, profile i prywatne dane), projekt opisuje produkt w Git, a ticket jest jednostką pracy z celem, testami i powiązaniem z Issue/PR. GLM53/GPT6/Opus5 są wykonawcami wybieranymi według benchmarku.
- Architektura, struktury katalogów i cykl projektu
- Etapy implementacji, migracja i kryteria odbioru
- Schematy danych i szablony
Docelowo projekt przechodzi: workspace → ticket → Issue → branch → implementacja
→ testy konkretnego SHA → PR → kontrolowany merge → opcjonalny tag/release.
Kod pozostaje w repo projektu; konfiguracja środowiska i prywatne dane należą do
workspace. Tickety są w project/ zgodnie z zasadami danego repo, a wykonawca nie
może sam zastąpić niezależnej weryfikacji przed publikacją.
Etap P0 dostarcza pełny import wybranego runtime i kontener projektu (twin prepare,
twin test). Integracja trzech wykonawców napraw z tym kontenerem pozostaje
następnym etapem. Projekt z własnym runtime blokuje uruchomienie naprawy przez
zastępczego Pythona aplikacji. Kopie archiwalne workspace i kontenery twin
są odrębnymi operacjami.
src/gitive/ # pakiet: CLI, serwer, panel, workspace i integracja noVNC
tests/ # testy aplikacji
vendor/ # zależność Subactor wraz z manifestem integralności
contracts/ # schematy workspace, projektu i ticketu
templates/ # wzorce środowisk control/browser/project i struktury projektu
Dockerfile
compose.yaml
glm53/ # pierwszy silnik napraw
gpt6/ # drugi silnik napraw
opus5/ # trzeci silnik napraw
benchmark/ # wspólne przykłady, wykonanie i raporty po timestamp
runs/
docs/ # dokumentacja, analizy i zapisy weryfikacji
pyproject.toml # instalowalny pakiet i entry point gitive
gitive # launcher CLI z checkoutu
Makefile
CLI wymaga Pythona ≥ 3.11. Pełna aplikacja wymaga Docker Engine z Compose, Git, make oraz skonfigurowanego istniejącego subactor/llm-account-hub. Obecny launcher jest przeznaczony dla lokalnego Linuksa: korzysta z usługi użytkownika llm-account-hub.service, konta softreck i sieci llm-account-hub-network. Nie instaluje samodzielnie całego huba.
Z katalogu tego repozytorium:
python3 -m venv .venv
. .venv/bin/activate
python3 -m pip install .
make startmake start przygotowuje prywatne kopie, sprawdza mounty, uruchamia aplikację oraz
usługę użytkownika gitive-host (testy/terminale/synchronizacja z WWW) i otwiera w przeglądarce:
Domyślna lokalizacja huba to /home/tom/github/subactor/llm-account-hub; można ją wskazać przez LLM_HUB_ROOT. Dostęp noVNC bez hasła pozostaje ograniczony do interfejsu loopback. Pierwsze przygotowanie może potrwać ze względu na kopiowanie danych istniejących pulpitów.
./gitive menu # stan, wykonane operacje i dostępne następne kroki
./gitive status
./gitive shell # interaktywny shell komend Gitive
./gitive stop # zatrzymaj pracę pętli aplikacji
make stop # zatrzymaj panel i worker hosta; noVNC pozostaje uruchomionyPo instalacji przez pip można używać gitive zamiast ./gitive. CLI łączy się z działającą usługą; adres można zmienić przez GITIVE_URL. Sama instalacja paczki nie uruchamia serwera ani nie instaluje trzech silników benchmarku.
W głównym ./.env skonfiguruj wspólne ustawienia LiteLLM/OpenRouter:
OPENROUTER_API_KEY=sk-or-v1-...
LLM_MODEL=openrouter/zai/glm-5.3Wstaw własny klucz; przykład nie jest działającym credentialem. Wywołania live korzystają z płatnego endpointu. Praca kontrolera odbywa się w prywatnej kopii repozytorium, więc późniejsza edycja .env na PC nie jest automatycznie przenoszona do już istniejącej kopii. Nie dodawaj kluczy do Git ani raportów.
./gitive benchmark
./gitive status
./gitive rank
./gitive project add moj-projekt /home/tom/github/organizacja/projekt \
--goal 'Napraw błędy wykrywane przez testy' \
--test 'python3 -m unittest discover -s tests' --allow src
./gitive project list
./gitive project run moj-projekt --cycles 3
./gitive project watch moj-projekt --interval 60Dodanie projektu importuje jego kopię. Ranking korzysta z aktualnego, kompletnego benchmarku live: trzy rozwiązania wykonują po trzy iteracje na tych samych trzech projektach testowych. Raporty są zapisywane w benchmark/runs/<timestamp-id>/ kopii roboczej. Szczegóły metodologii i zapisów wywołań LLM opisuje benchmark/README.md.
Aktualny development obsługuje poprawki 1–5 istniejących plików Python w zadanym zakresie oraz testy uruchamiane jako lista argumentów. Nie jest generatorem dowolnej aplikacji od zera. Dostępność etapu Codex zależy od wdrożonego API i uprawnień huba; nieudany preflight blokuje wykonanie. Integracje GitHub i warunki publikacji opisują README poszczególnych silników — lokalny sukces testów nie oznacza automatycznie wykonanego Issue → PR → merge.
| Silnik | Opis | Testy |
|---|---|---|
| GLM53 | Fakty append-only w Git, krytyk i obsługa napraw PR | make -C glm53 test |
| GPT6 | Kontroler GitHub, pamięć, weryfikacja SHA i publikacja | python3 gpt6/scripts/test_all.py |
| Opus5 | Ranking zadań i sprzężenie zwrotne z Git/CI | python3 opus5/tools/offline_test_runner.py |
Operacje workspace są dostępne w CLI, interaktywnym shellu i formularzach panelu. Zatrzymaj pętlę przed rozpoczęciem kopiowania. Zamknij na PC przeglądarkę, której profil zamierzasz skopiować.
./gitive stop
./gitive workspace inspect
./gitive workspace inventory
# Projekt wraz z wybranym profilem Firefox z PC:
./gitive workspace snapshot moj-projekt \
--project organizacja/projekt --browser firefox
./gitive workspace status
# Po zakończeniu wybierz snapshot z listy z datą i godziną:
./gitive workspace clone --target kopie/projekt
./gitive workspace status
# Po zakończeniu clone wybierz kopię z listy:
./gitive workspace resync --dry-run --include-sessions
./gitive workspace status
./gitive workspace resync --apply --include-sessions
./gitive workspace status
./gitive workspace resume --application terminalMożesz pominąć ID: ./gitive workspace resync wybierze jedyną kopię lub pokaże
listę wyboru w terminalu. W skrypcie przy kilku kopiach wymagane jest jawne ID; w terminalu wybierasz numer.
Domyślnie jest to podgląd; --apply zapisuje zmiany, a --include-sessions
obejmuje również wcześniej skopiowane profile. Bez istniejącej kopii potrzebny
jest najpierw snapshot i clone. CLI wyświetla wtedy instrukcję krok po kroku
z przykładowymi komendami, wyborem przeglądarki i sposobem odczytania ID.
workspace status pokazuje ostatnią operację i podpowiedź następnego kroku.
Sam status nie wykonuje kopii; zakończony snapshot nie oznacza wykonanego clone
ani aktywowania profilu w noVNC. Domyślnie CLI pokazuje krótkie podsumowania. Pełne dane są dostępne przez
--json, np. ./gitive workspace status --json lub ./gitive workspace inspect --json.
Operacje wykonują się w tle — przed kolejną zależną operacją poczekaj na zakończenie widoczne w workspace status. Dodanie --include-sessions do snapshotu obejmuje również obsługiwane dane sesji CLI/LLM/IDE. --browser wybiera firefox, chrome, chromium, all lub none.
Snapshoty są szyfrowane przez age. Profile PC po odtworzeniu pozostają kopiami offline; nie zastępują automatycznie aktywnej przeglądarki noVNC. Klucz identity.age w prywatnym magazynie workspace wymaga osobnej kopii zapasowej.
Osobne komendy obsługują profil istniejącego konta noVNC softreck, a nie profil PC:
./gitive workspace profile snapshot --browser firefox
./gitive workspace status
./gitive workspace profile restoreSnapshot/restore profilu huba może zatrzymać pulpit i jego procesy. Skrót Chromium noVNC — data na pulpicie pokazuje ostatni zapis plików sesji Chromium, odświeżany co minutę; nie jest potwierdzeniem importu Chrome z PC.
- PC jest źródłem tylko do odczytu. Praca agentów i resync zapisują prywatne kopie w
~/.local/share/gitive-isolated; noVNC nie ma współdzielonego do zapisu oryginalnego katalogu projektów. - Importowane są wskazane projekty, a nie całe
~/github. Zmiany w kopii blokują resync zamiast być automatycznie nadpisywane. Nie ma automatycznej synchronizacji zwrotnej na PC. - Obecny import nie jest pełną kopią środowiska: zachowuje m.in.
.git,.envi zwykłe pliki nieśledzone, ale pomija.venv,venv,node_modules,.subactori cache. Zewnętrzne symlinki oraz repozytoria z zewnętrznym.gitwymagają osobnego eksportu. - Pełna kopia wszystkich plików projektu, identyczna ścieżka jak na PC oraz osobny kontener z dokładnie zgodnym Pythonem, Node i bibliotekami systemowymi to wymagania jeszcze niewdrożone.
- Kopia profilu nie odtwarza procesów RAM. Restart kontenera nie oznacza automatycznego wznowienia zadania Codex.
make test-loop # testy pakietu aplikacji
make test # wszystkie zestawy repozytoriumPo przeniesieniu do src/gitive przeszło 29 testów aplikacji; sprawdzono budowę i instalację wheel, uruchomienie kontenera oraz izolację mountów. Nie jest to deklaracja pełnej zgodności środowiska z PC.
Menu stanu jest dostępne także na początku panelu WWW i po wejściu do ./gitive shell.
W shellu wpisz numer pozycji lub menu, aby odświeżyć widok. Menu pokazuje ostatnią
operację oraz zapisane snapshoty i kopie; nie przedstawia samego snapshotu jako
odtworzonej przeglądarki. Podgląd menu nie uruchamia kopiowania ani płatnego benchmarku.
W interaktywnym shellu wpisz sync lub pomoc, aby zobaczyć instrukcję
PC → kopia → resync. Ta sama instrukcja: ./gitive sync-help. Statusy i podpowiedzi
są kolorowane w terminalu; NO_COLOR=1, przekierowanie do pliku i --json
pozostawiają wyjście bez kolorów.
Snapshoty i kopie można wybierać z datowanej listy, bez ID: workspace clone,
workspace resync, workspace resume i workspace profile restore. Wybór jest
numerowany; czas podawany jest w Europe/Warsaw. Clone pyta także o nowy katalog,
jeśli pominięto --target. Starsze rekordy bez daty są oznaczone jawnie.
Ręczne ID pozostają obsługiwane w skryptach; pełne rekordy dostępne przez --json.
Walidacja nowych kontraktów (bez uruchamiania kontenerów lub publikacji):
python3 -m pip install ".[contracts]"
make test-contractsAktywne tickety są zarządzane przez semcod/planfile, lokalnie w .planfile/
prywatnej kopii projektu. Gitive używa wspólnego adaptera dla GLM53/GPT6/Opus5.
Jawna synchronizacja GitHub korzysta z natywnego GitHubBackend i lokalnego gh
(lub GH_TOKEN/GITHUB_TOKEN), bez zapisywania tokenu w konfiguracji ticketu.
./gitive tickets list doctor-agent
./gitive tickets create doctor-agent --title 'Sprawdzenie integracji' --engine glm53 --key unikalny-klucz
./gitive tickets sync doctor-agent --repo subactor/doctor-agent --direction push
./gitive tickets sync doctor-agent --repo subactor/doctor-agent --direction pullpush tworzy/aktualizuje zdalne Issue, pull odczytuje powiązane Issue. Przy
konflikcie operacja zatrzymuje się bez nadpisania. Samo uruchomienie pętli Gitive
zapisuje lokalny ticket; publikacja pozostaje jawna. Bezpośrednie uruchomienie
samodzielnych CLI silników nie przechodzi przez ten adapter Gitive.
Kontener zawiera zweryfikowany wheel Planfile. Dla CLI na innym hoście zainstaluj
python3 -m pip install src/gitive/vendor/planfile-0.1.124-py3-none-any.whl.
Przy imporcie klientów PC można jawnie pominąć aktywną sesję tej rozmowy:
--include-sessions --exclude-session .codex. Wykluczenie zostaje zapisane w manifeście.
Po ukończeniu workspace snapshot i workspace clone uruchom na hoście:
./gitive workspace activate --browser firefox --include-sessions
./gitive workspace activate --browser chromePolecenie pozwala wybrać kopię z listy, zachowuje poprzednie profile i restartuje
prywatny pulpit. Wymaga przygotowanej zgodnej wersji przeglądarki w
desktop/browser-install.json prywatnego magazynu. Instalacja wersji nie jest
jeszcze automatyczna. Skróty na pulpicie zawierają datę i godzinę importu.
workspace resync aktualizuje kopię offline; ponowna aktywacja jest osobnym krokiem.
Sesje uwierzytelnienia mogą wymagać ponownego logowania. Nie kopiuj aktywnej sesji
Codex tej rozmowy; użyj --exclude-session .codex przy snapshot.
Raport wdrożenia i ograniczenia.
Na hoście PC, po zarejestrowaniu projektu:
./gitive twin plan doctor-agent
./gitive twin prepare doctor-agent
./gitive twin status doctor-agent
./gitive twin test doctor-agent
./gitive twin exec doctor-agent -- python --versionprepare kopiuje cały wybrany projekt (także .env, .venv, venv,
node_modules) oraz wykryty prefiks Pythona i NVM Node. Zachowuje pierwotne
ścieżki wewnątrz kontenera. --include-path dodaje wybraną zależność poza repo; twin extend NAZWA --include-path ŚCIEŻKA uzupełnia istniejący workspace;
--python, --node, --image pozwalają określić środowisko jawnie. Automatyczny
obraz bazowy obsługuje Ubuntu; zgodność dotyczy skopiowanych runtime i testów,
nie wszystkich pakietów systemowych PC.
Planfile z poprzedniej aktywnej kopii jest zachowany; konflikt dwóch różnych
magazynów blokuje migrację. Nie usuwa się starych kopii. twin recover NAZWA
wycofuje wyłącznie niedokończoną transakcję rejestru. twin test wykonuje
zarejestrowaną komendę testów; dodatkowe ustawienia przekazuj przez --env NAZWA=wartość.
Polecenia twin wymagają hosta z Docker CLI. Kontener aplikacji/noVNC nie otrzymuje
socketu Docker. Po migracji project run/watch jest jawnie zablokowane do czasu
integracji adapterów napraw z nowym runtime; nie uruchamia testów zastępczym
Pythonem aplikacji. Obecne workspace resync nadal dotyczy kopii profili offline.