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 start

make 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:

• panel: http://127.0.0.1:8793/
• noVNC: http://127.0.0.1:6083/vnc.html?autoconnect=true&resize=scale

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 uruchomiony

Po 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.3

Wstaw 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 60

Dodanie 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.

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 terminal

Moż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 restore

Snapshot/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, .env i zwykłe pliki nieśledzone, ale pomija .venv, venv, node_modules, .subactor i cache. Zewnętrzne symlinki oraz repozytoria z zewnętrznym .git wymagają 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 repozytorium

Po 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.

• Dokumentacja aplikacji, komendy i historia weryfikacji
• Indeks dokumentacji
• Benchmark

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-contracts

Aktywne 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 pull

push 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 chrome

Polecenie 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 --version

prepare 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.

Raport wdrożenia P0: kontener doctor-agent i 238 testów.