install-maintenance-graft-rtk-ponytail-lite

Prompt

# Zweryfikowana instalacja i konserwacja — Graft + RTK + Ponytail lite

Pracujesz w bieżącym repozytorium, aby zainstalować, zaktualizować, naprawić lub zweryfikować ten stos:

- Graft: zrozumienie kodu, lokalny graf i wzbogacenie LSP.
- RTK: redukcja szumów w terminalu.
- Ponytail: lekka polityka, z natywną integracją, gdy jest kompatybilna.

Zacznij od inwentaryzacji tylko do odczytu. Następnie zadaj poniższe brakujące pytania.
Po uzyskaniu odpowiedzi wykonaj autoryzowane operacje aż do końcowych kontroli.

Nie rozpoczynaj instalacji przed ustaleniem klientów i zakresu.
Nie pytaj ponownie o decyzję już podjętą w tej rozmowie.

## 1. Inwentaryzacja, potem wybór użytkownika

### Inwentaryzacja bez modyfikacji

Zidentyfikuj:

- OS, architekturę, powłokę, środowisko: lokalna maszyna, WSL, SSH, kontener;
- katalog główny repozytorium, worktree, status Git i trwające operacje Git;
- aktualne ścieżki, wersje i metodę instalacji Git, Node, npm, RTK, Graft oraz dostępnych klientów;
- Claude Code, Codex, Kimi, Cursor Agent CLI i Cursor IDE osobno;
- Gemini, Copilot CLI lub innych klientów już obecnych jako opcjonalne cele;
- faktycznie używane katalogi konfiguracyjne, zmienne przekierowań oraz wszelkich orkiestratorów takich jak AgentsRoom;
- istniejące konfiguracje użytkownika, projektu, wtyczek i dziedziczone hooki.

Zweryfikuj tożsamość `agent` przed uznaniem go za Cursor.
Obecność binarki nie dowodzi uwierzytelnienia, funkcjonalności hooka ani załadowania MCP.

Nie uruchamiaj automatycznych aktualizacji, połączeń ani instalacji podczas tej inwentaryzacji.
Nie publikuj żadnych wartości tajnych.

Przedstaw krótką tabelę:
Klient | Binarka/wersja | Efektywna konfiguracja | Znany status.

### Pytania do zadania w jednej partii

Zadaj tylko pytania, na które brakuje odpowiedzi:

1. Operacja:
   - Zainstaluj brakujące komponenty i zachowaj kompatybilne wersje.
   - Zaktualizuj stos do zweryfikowanych stabilnych wersji.
   - Napraw istniejącą instalację, zachowując jej wersje.
   - Tylko weryfikuj, bez modyfikacji.

2. Klienci:
   - Wszyscy wykryci klienci.
   - Wybór z faktycznie wykrytej listy.
   - Przygotuj też konfigurację dla niektórych nieobecnych klientów.

3. Zakres integracji:
   - Projekt współdzielony: przenośne konfiguracje przeznaczone dla repozytorium.
   - Projekt osobisty: aktywacja dla tego repozytorium, pliki lokalne nie wersjonowane.
   - Użytkownik globalny: aktywacja dla projektów tego użytkownika.
   - Mieszany: odrębny wybór według klienta lub komponentu.

Jeśli zakres jest mieszany, zapytaj tylko o niezbędne wyjaśnienia.

Dla aktualizacji zapytaj też o ewentualne ograniczenia wersji, jeśli nie są znane.
W przeciwnym razie zaproponuj wyraźne stabilne wersje.

Nie instaluj ani nie aktualizuj samych aplikacji klienckich:
operacja dotyczy Graft, RTK, Ponytail i ich niezbędnych zależności.
Przestarzały klient jest zgłaszany z wymaganą wersją i dalszym działaniem.

### Uczyń wybory konkretne

Przed zapisaniem wyświetl planowany rezultat:

Komponent/klient | Docelowa wersja | Zakres | Docelowe pliki | Efekt współdzielony | Plan awaryjny

Wyjaśnij w szczególności:

- Wykonywalny plik zainstalowany na poziomie użytkownika może służyć wielu repozytoriom.
- Aktualizacja tego pliku wpływa na wszystkich jego lokalnych użytkowników.
- Wtyczka może mieć globalny cache, ale aktywację na projekt.
- Hook na projekt może nadal korzystać ze stanu współdzielonego.
- Indeks Graft pozostaje specyficzny dla repozytorium/worktree.
- Globalna konfiguracja dostarczona przez orkiestratora może być izolowana do projektu: zweryfikuj faktyczny zakres, nie tylko nazwę.

Po uzyskaniu wyborów kontynuuj bez powtarzających się potwierdzeń.
Poproś o nową decyzję tylko, jeśli ograniczenie wymaga rozszerzenia zakresu lub zmiany rozwiązania materialnego.

## 2. Zasady wykonania

Kolejność:
inwentaryzacja → wybór → kopie zapasowe → RTK → Graft/LSP → Ponytail → instrukcje → weryfikacje → raport.

Przestrzegaj instrukcji repozytorium i zarządzanych polityk.
Jeśli plik jest zarządzany przez AgentsRoom lub innego orkiestratora,
użyj jego oficjalnego mechanizmu; nie modyfikuj bezpośrednio generowanych plików.

Przed każdą modyfikacją:

- zwaliduj format I strukturę konfiguracji JSON/JSONC/TOML;
- wykonaj kopię zapasową zmienianych plików poza repozytorium, z ograniczonym dostępem;
- zanotuj wersje i elementy niezbędne do rollbacku;
- przejrzyj symulację instalatora, jeśli istnieje.

Nieprawidłowy plik nigdy nie może zostać zastąpiony pustą konfiguracją.

Scal konfiguracje zachowując inne MCP, hooki, uprawnienia, instrukcje, komentarze gdy to możliwe oraz linie statusu.
Nie zmieniaj reguł zatwierdzania ani odcisków zaufania.

Zachowaj istniejące zmiany Git. Bez commitów, push, resetów, clean, stash ani zmian w kodzie aplikacji.
W przypadku nierozwiązanego konfliktu lub trwającej operacji Git, wstrzymaj zapisy w repozytorium; kontynuuj niezależną diagnostykę.

Nie instaluj Graphify, CodeGraph, Caveman ani Headroom.
Stara konfliktowa integracja jest usuwana tylko po precyzyjnej identyfikacji, kopii zapasowej i w ramach autoryzowanego zakresu.
Nie odinstalowuj globalnie narzędzia używanego gdzie indziej.

Błąd blokuje zależne od niego kroki, nie inne niezależne klientów.
Nie deklaruj kroku jako udanego, aby obejść ograniczenie.

## 3. Możliwości i zakres: weryfikuj przed konfiguracją

Konsultuj pomoc zainstalowanych wersji oraz dokumenty odpowiadające publikowanym wersjom, których użyjesz:

- https://github.com/rtk-ai/rtk
- https://github.com/trailhq/Graft
- https://github.com/DietrichGebert/ponytail
- oficjalna dokumentacja każdego wybranego klienta.

Główna gałąź/develop może opisywać funkcje nieobecne w wydaniu.
Dla wątpliwej opcji sprawdź wydanie, pomoc lub dostarczony kod.

Ustal dla każdej integracji:

Klient | Dostępne hooki projektowe | Kompatybilny instalator |
Zakres aktywacji | Zakres stanu | Dowód

Nie myl:
"klient akceptuje hooki projektowe"
oraz "instalator tego narzędzia potrafi je zainstalować na poziomie projektu."

Punkty kontrolne do ponownej weryfikacji w obecnych wersjach:

- Claude: ustawienia użytkownika, projekt współdzielony i projekt lokalny.
- Cursor: haki użytkownika i projektu; testuj IDE i CLI osobno.
- Codex: konfiguracje użytkownika/projektu i aktywacja wtyczek;
  zweryfikuj faktycznie dostępne mechanizmy haków.
- Kimi: nie zakładaj konfiguracji haków per projekt;
  rozróżniaj konfigurację użytkownika, instrukcje projektu i opcje uruchomienia.
- Gemini/Copilot: zweryfikuj ich własne mechanizmy, jeśli wybrane.

Jeśli instalator nie respektuje żądanego zakresu:

1. Poszukaj odpowiedniej oficjalnej opcji.
2. W przeciwnym razie użyj udokumentowanej ręcznej konfiguracji tego samego adaptera,
   tylko jeśli jego protokół i ścieżki pozostają kompatybilne.
3. W przeciwnym razie użyj obejścia przez jawne instrukcje/prefiks.
4. Nigdy nie przełączaj się cicho na globalny.

Sprawdź dziedziczone haki globalne przed dodaniem ich lokalnych odpowiedników:
mogą się kumulować zamiast zastępować nawzajem.
Zachowaj haki bezpieczeństwa. Zgłaszaj globalne efekty, które pozostają aktywne.

## 4. RTK

Sprawdź pochodzenie `rtk-ai/rtk`, wersję, pomoc, konfigurację
oraz `rtk gain`. Błąd `gain` może pochodzić z bazy lub uprawnień:
to nie jest wystarczający dowód na zły pakiet.

Zainstaluj lub zaktualizuj za pomocą już używanego menedżera, jeśli to stosowne.
Sprawdź pochodzenie formuły lub pakietu oraz uzyskaną wersję.
Unikaj równoczesnych instalacji i niepotrzebnych zmian PATH.
Nie uruchamiaj bezmyślnie `cargo install rtk`.

Konsultuj `rtk init --help` dla wybranej wersji.
Wybieraj opcje według klienta i zakresu; nie kopiuj systematycznie
`-g` z przykładu dokumentacji.

Nie zakładaj, że integracja Codex to zawsze prosta instrukcja,
ani że zawsze ma hak: to zależy od wersji RTK.
Sprawdź też niezgodności między opcjami inicjalizacji.

W faktycznie odczytanej konfiguracji scal wykluczenia:

    [hooks]
    exclude_commands = ["graft", "curl", "playwright"]

Zachowaj istniejące wykluczenia i zweryfikuj ich uwzględnienie.
Jeśli to ustawienie jest globalne, wskaż ten efekt przed jego modyfikacją.
Wyłącz opcjonalną telemetrię za pomocą udokumentowanego mechanizmu,
w dozwolonym zakresie.

RTK jest jedynym komponentem uprawnionym do przepisywania poleceń powłoki.
Haki bezpieczeństwa, audytu i zatwierdzenia pozostają stosowalne.

Nie kopiuj haka Claude do innego klienta bez udokumentowanej kompatybilności.
Bez skutecznego przepisywania skonfiguruj jawny prefiks `rtk`.
Unikaj podwójnych haków i podwójnych prefiksów.

## 5. Graft z LSP

### Instalacja i prywatność

Zweryfikuj tożsamość pakietu `@nanonets/graft`, jego opublikowaną wersję
oraz wymagania Node.

Zainstaluj poza zależnościami aplikacji, w odpowiednim miejscu.
Nie modyfikuj package.json ani pliku blokady projektu, aby zainstalować Graft.

Stosuj `DO_NOT_TRACK=1` od pierwszego uruchomienia i w MCP.
Użyj oficjalnej komendy wyłączającej telemetrię, jeśli jest dostępna.

Nie aktywuj Brain, konta, wzbogacania LLM ani `--deep`.
Nie obiecuj zerowego ruchu sieciowego bez jego weryfikacji.

Nie uruchamiaj automatycznie `graft init`.
Preferuj jawne okablowanie; jego instalator może pisać poza repozytorium.

### Prawdziwie operacyjny LSP

Przed eksploracją kodu aplikacji przestrzegaj reguł Graft repozytorium.
Następnie zidentyfikuj użyteczne języki i sprawdź integracje LSP
wybranej wersji Graft.

Wykorzystaj ponownie kompatybilne serwery już obecne.
Zainstaluj tylko niezbędne serwery, z zarejestrowanymi wersjami,
poza zależnościami aplikacji, jeśli to możliwe.

Sprawdź:

- plik wykonywalny i jego wersję;
- dostępność w PATH procesu Graft/MCP;
- wymagania językowe i workspace;
- wsparcie przez tę wersję Graft.

Po przeczytaniu pomocy użyj w szczególności, jeśli dostępne:

    graft build --lsp --no-ignore --no-gitignore
    graft check
    graft ask "Gdzie są główne punkty wejścia i trasy API, jeśli są?" --source

Zastosuj DO_NOT_TRACK do tych poleceń z aktualną składnią powłoki.

Sprawdź znaczenie opcji: w niektórych wersjach,
`--no-ignore` i `--no-gitignore` zapobiegają zapisywaniu plików wykluczeń;
nie oznaczają "indeksuj ignorowane pliki."

Jawnie zarządzaj wykluczeniem Git `/graft/` zgodnie z wybranym zakresem.
Zweryfikuj to za pomocą Git. Nie usuwaj automatycznie żadnych już śledzonych plików.
Zachowaj adnotacje i treści tworzone przez ludzi.

Budowa z `--lsp` i kodem wyjścia 0 nie dowodzi użycia LSP.
Szukaj ukierunkowanych dowodów: faktyczne uruchomienie serwera, wynik rozwiązywania,
wzbogacone krawędzie lub udokumentowane diagnostyki.

Raportuj według języka:
LSP zweryfikowany / dostępny bez zaobserwowanego wzbogacenia / niedostępny / nieobsługiwany.

Nigdy nie ładuj całego grafu ani wiring.json w kontekście.
Sprawdź też, czy wzbogacenie LSP utrzymuje się po automatycznym odświeżeniu;
jeśli nie jest to gwarantowane, udokumentuj potrzebę jawnej rekonstrukcji.

### MCP i świeżość

Skonfiguruj pojedynczy skuteczny wpis Graft na klienta.
Odkryj faktycznie obsługiwany plik, schemat i zakres.

Dla każdego serwera zweryfikuj:
zainstalowane polecenie, argumenty MCP, DO_NOT_TRACK, PATH i katalog roboczy.

Nie zakładaj, że `.kimi-code/mcp.json`, `.mcp.json` lub inny plik jest automatycznie ładowany: potwierdź mechanizm klienta lub niezbędną opcję uruchomienia.

Globalna konfiguracja MCP jest dopuszczalna tylko jeśli docelowy proces poprawnie adresuje każde repozytorium. W przeciwnym razie trzymaj MCP na poziomie projektu.

Nie używaj `npx -y ...@latest` przy każdym starcie.
Nie kontroluj wersji absolutnych ścieżek osobistych ani sekretów.
Nie wymyślaj uniwersalnej zmiennej `${workspaceFolder}`.

W tym profilu nie dodawaj żadnych haków Graft.
Brak smart-grep, grep-redirect ani przechwytywania powłoki Graft.

Sprawdź odświeżanie i brak niezamierzonego wyłączania.
Nieudane odświeżenie zabrania prezentowania grafu jako świeżego.

Sprawdź stare integracje i metadane auto-okablowania przed migracją.
Usuwaj tylko zidentyfikowane i zarchiwizowane elementy.
Zweryfikuj, że nie pojawiają się ponownie po starcie MCP i zapytaniu.

### Statystyki Graft

Oddziel operację, obserwowane użycie i zbieranie statystyk.

W zależności od wersji, `graft stats` zależy od hooków sesji.
Bez tych hooków można spodziewać się komunikatu „no session recorded yet” mimo pomyślnych żądań Graft.

Nie fabrykuj statystyk ani nie uruchamiaj `graft init`, aby ten komunikat zniknął.

Jeśli użytkownik wymaga natywnych statystyk, ujawnij kompatybilność dostępnych hooków pomiarowych i wyraźnie poproś o ewolucję profilu bez hooków przed jakąkolwiek aktywacją.

## 6. Ponytail lite

Preferuj oficjalną integrację kompatybilną z klientem i zakresem.
Sprawdź jej manifest, zdarzenia i zależności.

Rozróżnij:
instalację wtyczki, aktywację, tryb domyślny i aktualny stan trybu.

Sprawdź faktycznie odczytywane źródła:
konfigurację, `PONYTAIL_DEFAULT_MODE`, stan trwały i dane wtyczki.
`defaultMode: lite` nie dowodzi, że stary pełny stan został zastąpiony.

Jeśli tryb jest współdzielony między rozmowami, wskaż to.
W zakresie projektu nie zmieniaj globalnego domyślnego trybu bez powiadomienia.
Użyj udokumentowanego lokalnego mechanizmu lub polityki lite według instrukcji.

Według klienta:

- Claude/Codex: oficjalna instalacja i aktywacja w dostępnym zakresie.
  Sprawdź podpolecenia przed ich użyciem.
  Zgody na hooki pozostają po stronie użytkownika.
- Cursor: oficjalny adapter lub reguła instrukcji; unikaj ich kumulacji.
  Jeśli istnieje `scripts/cursor-hooks.js install --project`, uruchom skrypt
  z katalogu głównego docelowego repozytorium, używając oficjalnej ścieżki checkout.
  Bez `--project` sprawdź miejsce docelowe użytkownika.
  Sprawdź wygenerowane ścieżki: hook projektu zawierający ścieżkę absolutną
  do osobistego checkoutu nie jest przenośny i nie powinien być zatwierdzany.
- Kimi: poszukaj kompatybilnego oficjalnego adaptera. W przeciwnym razie polityka lite
  w AGENTS.md; dodaj minimalną lokalną umiejętność tylko jeśli jest użyteczna
  i jeśli jej format oraz ładowanie są potwierdzone.
  Zidentyfikuj ją jako adaptację, bez obiecywania natywnych poleceń lub statystyk.
- Inni wybrani klienci: stosuj tę samą weryfikację, bez automatycznego przenoszenia
  zdarzeń Claude/Codex.

Zachowaj checkout adaptera na zidentyfikowanej wersji lub commicie.
Nie wykonuj git pull na zmodyfikowanym checkout.
Nie dodawaj statusline ani wskaźnika wizualnego.

Przetestuj faktyczny tryb w nowej sesji.

## 7. Kompaktowe instrukcje wspólne

Scal blok ograniczony przez:

    <!-- agent-stack:start -->
    ...
    <!-- agent-stack:end -->

w AGENTS.md. Zachowaj całą zawartość zewnętrzną i dodatki ludzkie.
Nie kopiuj tego promptu instalacyjnego do instrukcji agenta.

Blok musi wyrażać:

### Graft

Aby zrozumieć lub zmodyfikować kod, najpierw eksploracja aplikacji:
`graft ask "<precyzyjne pytanie>" --source`, lub faktycznie udostępnione narzędzie MCP Graft.

Instrukcje, umiejętności, Git, konfiguracje i odkrywanie MCP mogą poprzedzać.
Po orientacji czytaj bezpośrednio użyteczne fragmenty.
Dla wywołujących używaj dostępnych poleceń/narzędzi śledzenia.

W przypadku przestarzałego grafu: sprawdź, dostosuj rekonstrukcję z LSP, potem nowe zapytanie.
Po nieudanym wyszukiwaniu: celowany graft grep, potem bezpośrednie czytanie
lub ograniczony rg z wyjaśnieniem limitu.

Dostarczony plik, stack trace, konfiguracja lub nieindeksowany język
umożliwiają bezpośrednie celowane czytanie.
Brak w grafie nie dowodzi braku kodu lub wywołań.

Po modyfikacjach: graft blast, zweryfikowana baza Git i odpowiednie testy.
Bez --name, bez pełnego ładowania grafu.
Zgłoś faktyczną liczbę wywołań i wszelkie błędy.

### RTK

Zweryfikowany hook: pozwól na działanie przepisywania bez podwójnego prefiksu.
W przeciwnym razie: wyraźnie poprzedzaj kompatybilne polecenia prefiksem.
Nigdy nie przekazuj Graft przez RTK.

Dla pełnego outputu: przypomnij --full jeśli dostępne, lub proxy.
Nie uruchamiaj automatycznie ponownie polecenia z efektami ubocznymi.
Zachowaj potoki i przekierowania.

Przed walidacją: rzeczywiste nieskompresowane diffy, diff --cached,
diff --check i osobna inspekcja nowych plików.
Bez automatycznego stage'owania.

### Ponytail lite

Poprawnie zaimplementuj żądanie i wykorzystaj istniejące.
Krótko zgłoś znacznie prostsze rozwiązanie.
Zachowaj walidację, bezpieczeństwo, uprawnienia, dostępność, transakcje
oraz niezbędne testy. Zweryfikuj użycia przed usunięciem lub włączeniem.

Pełne tylko na wyraźne żądanie, nigdy ultra domyślnie.
Audyt nie wywołuje przeprojektowania.
Poprawka ma priorytet dla bezpieczeństwa, parserów, współbieżności i migracji.

Nie twierdź, że współdzielony tryb jest lokalny dla rozmowy.
Po autoryzowanym pełnym trybie, zweryfikuj powrót do lite.
Wyłączenie nie usuwa już wstrzykniętych instrukcji.

### Ładowanie

Potwierdź, jak każdy klient faktycznie ładuje te instrukcje.
Używaj udokumentowanych minimalnych importów/adapterów.
Unikaj duplikacji i importów cyklicznych.

RTK pozostaje jedynym przepisywaczem powłoki.
Brak hooka Graft w tym profilu.

## 8. Aktualizacja i Naprawa

Ten sam prompt musi dać się uruchomić ponownie bez duplikatów.

W trybie aktualizacji:

1. Ponownie odczytaj wybory zakresu i wcześniej zweryfikowany stan.
2. Porównaj zainstalowane wersje, wersje docelowe i niekompatybilne zmiany.
3. Wykonaj kopię zapasową przed każdą migracją.
4. Aktualizuj tylko wybrane komponenty.
5. Odśwież wtyczki/adaptery ich oficjalnym mechanizmem.
6. Ponownie oceń możliwości: stary fallback może zostać zastąpiony
   natywną integracją dostępną teraz w tym samym zakresie.
7. Migruj tylko klucze i bloki należące do tego stacku.
8. Odbuduj graf w razie potrzeby i ponownie sprawdź LSP.
9. Uruchom ponownie niezbędne procesy MCP/klienta:
   istniejący proces może nadal działać na starej wersji.
10. Powtórz kontrole i testy zmodyfikowanych integracji.

Nie reinstaluj niepotrzebnie komponentu, który jest już zgodny.
Nie uruchamiaj ogólnej aktualizacji pakietów maszyny.

W trybie naprawy zachowaj wersje z wyjątkiem wykazanej niekompatybilności
i wyraźnej decyzji o aktualizacji.

Przygotuj celowany rollback: poprzednie wersje, kopie zapasowe,
i dokładne polecenia. Nie przywracaj ślepo całego pliku
jeśli od jego kopii zapasowej zaszły inne zmiany.

Drugie wykonanie bez żądanych zmian nie może tworzyć
żadnego hooka, serwera MCP ani duplikatu sekcji instrukcji.

## 9. Kontrole i Dowody

Testuj osobno:

- Wykonywalna i jawna kompresja RTK;
- automatyczne wywoływanie hooków, wykluczenia i surowe przekazywanie;
- Graft: świeżość, wynik zgodny z repozytorium oraz wzbogacenie LSP;
- MCP: funkcjonalny serwer ORAZ faktyczne ładowanie w każdym kliencie;
- Ponytail: aktywacja i efektywny tryb;
- brak duplikatów i ponownego pojawiania się samoinstalacji;
- ostateczna ważność konfiguracji i efektywny zakres.

Obecność pliku nie jest dowodem na załadowanie.
Zewnętrzna sonda MCP nie jest dowodem na załadowanie w kliencie.
Jawny prefiks RTK nie jest dowodem na automatyczny hook.

Dla każdego dostępnego i uwierzytelnionego klienta otwórz nową sesję
w repozytorium, z jego zwykłymi zabezpieczeniami, i wydaj ten neutralny bilet:

"Bez modyfikacji kodu, zlokalizuj główne punkty wejścia.
Jeśli istnieje API, wskaż, gdzie są zamontowane jego trasy i wyznacz
ścieżkę do logiki biznesowej. Podaj pliki i linie."

Nie dodawaj "użyj Graft".
Sprawdź widoczne wywołania narzędzi, nie wewnętrzne rozumowanie.
Zachowaj minimalne dowody i zredaguj dane wrażliwe.

Jeśli brakuje zatwierdzenia, logowania lub akcji UI:
NIE TESTOWANO / AKCJA UŻYTKOWNIKA, nigdy nie zakładaj sukcesu.

## 10. Produkt końcowy

W ramach uprawnionego zakresu prowadź krótką dokumentację utrzymaniową:

- wybór operacji, klienci i zakres;
- dokładne wersje, pochodzenie i data weryfikacji;
- mechanizmy konfiguracji i ograniczenia;
- rekonstrukcja Graft/LSP;
- procedura aktualizacji, weryfikacji i wycofania.

Dla instalacji współdzielonej użyj `docs/agent-stack.md`.
Dla instalacji osobistej/globalnej nie umieszczaj informacji specyficznych dla maszyny
w plikach wersjonowanych.
W trybie tylko weryfikacji dostarcz raport bez tworzenia tych plików.

Zgłoś decydujące polecenia, ich wyniki, zmodyfikowane pliki,
kopie zapasowe i dokładne działania użytkownika.

Sporządź inwentaryzację końcowych hooków:
klient, pochodzenie, zakres, zdarzenie, matcher, rola i zredagowane polecenie.

Zakończ:

Klient/wersja | Efektywny zakres | Obecna konfiguracja |
MCP załadowany | Graft zaobserwowany przy pierwszej eksploracji |
LSP | RTK | Ponytail | Pozostałe dowody/akcje

Używaj jawnych stanów:
SKONFIGUROWANY / ZAŁADOWANY / ZAOBSERWOWANE UŻYCIE / NIE TESTOWANO / ZABLOKOWANY / NIE DOTYCZY.

Klasyfikuj pliki:
DO ZATWIERDZENIA PO PRZEGLĄDZIE / DO IGNOROWANIA / KONFIGURACJA MASZYNY.

Ścieżki osobiste, sekrety, cache, grafy, kopie zapasowe i transkrypcje
nie mogą być dołączane do plików do zatwierdzenia.

Wyświetl ostateczny status Git i zmiany wprowadzone przez tę interwencję,
wyróżniając je od zmian istniejących wcześniej. Nie zatwierdzaj niczego.

Tagi