--- service: "Publicasta" schema_version: "1.0" article_id: 860 title: "Spettro przenosi pracę z agentem kodującym do terminala i czyni uprawnienia częścią produktu" language: "pl" default_language: "en" canonical_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions?lang=pl" json_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions.json?lang=pl" api_url: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles/spettro_open_source_terminal_agent_explicit_permissions?lang=pl" channel_url: "https://publicasta.com/api/public/v1/channels/open_source_radar" channel_articles: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-10-12T06:48:36+00:00" updated_at: "2026-10-12T06:48:36+00:00" translations: - language: "ar" html_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions?lang=ar" markdown_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions.md?lang=ar" json_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions.json?lang=ar" - language: "de" html_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions?lang=de" markdown_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions.md?lang=de" json_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions.json?lang=de" - language: "en" html_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions?lang=en" markdown_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions.md?lang=en" json_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions.json?lang=en" - language: "es" html_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions?lang=es" markdown_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions.md?lang=es" json_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions.json?lang=es" - language: "fr" html_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions?lang=fr" markdown_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions.md?lang=fr" json_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions?lang=pl" markdown_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions.md?lang=pl" json_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions?lang=ru" markdown_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions.md?lang=ru" json_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions?lang=zh" markdown_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions.md?lang=zh" json_url: "https://publicasta.com/open_source_radar/spettro_open_source_terminal_agent_explicit_permissions.json?lang=zh" --- # Spettro przenosi pracę z agentem kodującym do terminala i czyni uprawnienia częścią produktu > Spettro to młody, otwartoźródłowy asystent programistyczny GPL-3.0, który łączy widoczne przekazywanie zadań między agentami, bramki akceptacji, wybór dostawcy modeli i sandboxing na poziomie systemu operacyjnego. Spettro to niewielki, otwartoźródłowy asystent programistyczny o celowo widocznym przepływie pracy. Działa w terminalu, oddziela planowanie od implementacji, pokazuje aktywnego agenta i tryb uprawnień oraz zachowuje wystarczająco dużo stanu, aby później wznowić zadanie. Projekt napisano w Go, wykorzystuje terminalowy interfejs Bubble Tea i jest wydawany na licencji GPL-3.0. W chwili sprawdzania repozytorium miało 37 gwiazdek i sześć forków, a najnowszym otagowanym wydaniem było v2.8.2 z 4 października 2026 roku. Te liczby mają znaczenie: to wciąż wczesny projekt do oceny, a nie ugruntowana podstawa firmowego procesu wytwarzania oprogramowania. ![Ilustracja redakcyjna terminalowego agenta programistycznego z widocznym planem, zatwierdzeniem, wywołaniami narzędzi i granicami uprawnień.](https://publicasta.com/storage/projects/10/pages/860/2026/10/96929361-a018-4cf5-ad01-70e43641fbb2.webp) Interesujące pytanie nie brzmi więc, czy Spettro może zastąpić dojrzałego asystenta kodującego. Tego nie potrafi jeszcze udowodnić. Trafniejsze pytanie brzmi: czy jego konstrukcja ułatwia nadzorowanie pracy wspomaganej przez agenta? Na tym węższym polu Spettro ma spójny punkt widzenia: agent powinien działać w zadeklarowanej granicy projektu, proponować pracę przed jej wykonaniem, korzystać z nazwanych ról zamiast jednego ogromnego promptu i pozostawiać ślad wywołań narzędzi, który programista może sprawdzić. To użyteczny kierunek dla open source. Wiele agentów kodujących konkuruje tym, ile kodu potrafią zmienić po jednym poleceniu. Spettro większą część powierzchni produktu poświęca temu, co dzieje się przed zmianą i wokół niej. Dlatego warto go wypróbować, jeśli ktoś chce badać kontrolę nad agentami, budować lokalne przepływy pracy albo współtworzyć młodą aplikację w Go. Ta sama cecha oznacza jednak długą listę powodów, by eksperymenty prowadzić w izolacji. ## Co właściwie dodaje Spettro Projekt opisuje się jako terminalowego, wieloagentowego asystenta programistycznego. To sformułowanie może brzmieć podobnie do rosnącej listy narzędzi wiersza poleceń, ale struktura Spettro jest bardziej konkretna. Repozytorium zawiera manifest agentów, pliki promptów, terminalowy interfejs użytkownika, konfigurację dostawców, obsługę przepływów, sesje trwałe, umiejętności, pamięć, hooki oraz osobny tryb ACP do integracji z edytorami. Wbudowane role obejmują planowanie, kodowanie, zadawanie pytań, eksplorację, pracę z Gitem, testowanie, przegląd i dokumentację. Najważniejszą jednostką nie jest pojedyncza rola, lecz przekazanie zadania. Agent planujący może przeanalizować repozytorium i zaproponować sekwencję zmian; agent kodujący może następnie wykonać zaakceptowany plan; później można wywołać role testowania i przeglądu. Manifest oraz pliki promptów są widoczne w repozytorium, a nie ukryte w nieprzejrzystej konfiguracji po stronie usługi. Nie gwarantuje to poprawnego wyniku, ale daje opiekunowi coś konkretnego do przeczytania, skopiowania i zmodyfikowania. Domyślna interakcja jest też celowo bardziej proceduralna niż pojedyncze okno czatu. Spettro prosi użytkownika o zaufanie do folderu projektu, podłączenie dostawcy modelu, wybór modelu i rozpoczęcie od agenta planującego. README opisuje polecenia takie jak `/plan`, `/approve`, `/permission`, `/models`, `/skills`, `/compact` i `/resume`. Ten słownik pokazuje, jak twórcy wyobrażają sobie korzystanie z narzędzia: sesja jest środowiskiem pracy, plan jest obiektem podlegającym przeglądowi, a tryb uprawnień należy do zadania, a nie do ukrytych szczegółów implementacji. Przynosi to praktyczną korzyść. Gdy sesja agenta pójdzie źle, diagnoza często nie brzmi po prostu: model był słaby. Bardziej prawdopodobne jest, że agent miał zbyt szeroki dostęp do systemu plików, zadanie nie zostało rozłożone na części, polecenie uruchomiono w niewłaściwym katalogu, nie sprawdzono wyniku narzędzia albo przerwana sesja straciła kontekst. Przepływ, który nazywa te etapy, daje operatorowi więcej miejsc na zatrzymanie pracy i kontrolę. ## Uprawnienia są głównym tematem Najmocniejszym argumentem Spettro jako projektu open source jest próba umieszczenia granicy uprawnień blisko warstwy wykonawczej. Strona projektu podaje, że polecenia objęte sandboxem mogą być ograniczane przez Seatbelt w macOS, Landlock w Linuksie oraz Mandatory Integrity Control w Windows. Dokumentacja opisuje także tryby dostępu do systemu plików, takie jak `off`, `workspace-write` i `read-only`, a także zasady sieciowe: `all`, `localhost`, `none` albo jawną listę portów. Te szczegóły są bardziej znaczące niż ogólna obietnica, że agent jest „bezpieczny”. Opisują powierzchnię polityki, którą operator może sprawdzić. Projekt podaje, że politykę można przekazać przez flagi wiersza poleceń albo manifest agenta, a model nie może jej odczytywać ani zmieniać. W środowisku agenta kodującego to właściwa granica do omawiania: model językowy może zasugerować polecenie powłoki, ale środowisko uruchomieniowe powinno decydować, czy polecenie może dotrzeć do pliku, katalogu, urządzenia lub adresu sieciowego. To rozróżnienie jest szczególnie ważne przy korzystaniu z modeli lokalnych albo usług zgodnych z API. Wybór dostawcy nie usuwa ryzyka wykonania. Model lokalny nadal może wygenerować destrukcyjne polecenie. Model hostowany nadal może źle zrozumieć repozytorium. Niewielki otwartoźródłowy runtime nadal może zawierać błąd w kontroli uprawnień. Sandbox zmniejsza promień rażenia, ale nie dowodzi, że każdy przepływ jest bezpieczny. Pierwszy test powinien być więc celowo nudny: ```text 1. Utwórz repozytorium tymczasowe, bez poświadczeń. 2. Uruchom Spettro w trybie tylko do odczytu albo pytania przed działaniem. 3. Poproś o plan opisujący wyłącznie niewielką zmianę. 4. Sprawdź proponowane wywołania narzędzi i ścieżki. 5. Zaakceptuj zmianę z oczywistym testem i łatwym wycofaniem. 6. Powtórz próbę przy wyłączonym dostępie do sieci. ``` Nie zaczynaj od wskazania katalogu domowego, produkcyjnego checkoutu, katalogu z kluczami SSH ani repozytorium mającego dostęp do poświadczeń wdrożeniowych. Udostępnienie trybów uprawnień jest powodem, by je przetestować, a nie powodem, by test pominąć. ## Bramka akceptacji pomaga, ale nie zastępuje przeglądu W bardziej restrykcyjnych trybach Spettro oddziela planowanie od wykonania za pomocą kroku `/approve`. To dobry wzorzec interakcji, ponieważ daje człowiekowi szansę sprawdzenia zakresu przed rozpoczęciem modyfikowania plików przez narzędzia. Tworzy też naturalne miejsce na własną listę kontrolną zespołu: dozwolone katalogi, oczekiwane pliki, testy do uruchomienia, generowane artefakty i polecenia, które muszą pozostać niedostępne. Jest jednak ograniczenie. Akceptacja może stać się rytuałem, jeśli plan jest zbyt szeroki albo trudny do przeczytania. Wiersz „zaktualizuj przepływ uwierzytelniania i napraw powiązane testy” nie staje się sensowną kontrolą tylko dlatego, że ktoś go zatwierdził. Użyteczny plan potrzebuje ograniczonego zbioru plików, uzasadnienia każdej zmiany i kroku weryfikacji. Spettro może pokazać przepływ, lecz jego jakość nadal zależy od promptów, instrukcji repozytorium i nawyków zespołu. To samo dotyczy autonomicznego trybu celu. Projekt opisuje polecenie `/goal`, które pozwala runtime’owi kontynuować pracę przez kolejne iteracje, wykrywać zatrzymania, wznawiać postęp i kończyć po oznaczeniu celu jako zrealizowanego. Może to być wygodne przy długich zadaniach, ale autonomia zwiększa znaczenie punktów kontrolnych. Pętlę celu należy traktować jak potok budowania z określonym przez człowieka budżetem i warunkiem wyjścia, a nie jak obietnicę, że agent sam będzie wiedział, kiedy zrobił wystarczająco dużo. Dla pojedynczego programisty rozsądnym środkiem jest używanie trybu celu tylko przy zadaniach z wąsko zdefiniowanym kryterium ukończenia. „Dodaj parser dla tych pięciu przykładów i napisz testy” da się sprawdzić. „Popraw architekturę” już nie. Gdy zadanie dotyka zależności, poświadczeń, migracji, plików wdrożeniowych albo kodu wrażliwego z punktu widzenia bezpieczeństwa, wróć do przepływu planowania i utrzymuj pętlę krótką. ## Wielu agentów nie oznacza automatycznie lepszego wyniku Spettro reklamuje równoległe uruchamianie podagentów oraz wyspecjalizowane role orkiestratora i pracowników. Może to pomóc, gdy praca naturalnie się dzieli: jedna rola eksploruje repozytorium, druga przygotowuje testy, kolejna sprawdza łatkę, a orkiestrator łączy wyniki. Może też marnować czas i tokeny, gdy kilka agentów powtarza to samo wyszukiwanie albo przedstawia wzajemnie sprzeczne sugestie. Wartość wynika z granic ról, nie z ich liczby. Dobry podział daje każdemu pracownikowi inne pytanie i jasny format wyjścia. Rola eksploracyjna może wskazać odpowiednie pakiety i istniejące testy; rola kodująca może zostać ograniczona do planu implementacji; rola przeglądu może szukać wyłącznie regresji i brakującego pokrycia. Jeśli każda rola dostaje to samo niejasne polecenie, równoległość jest tylko powieloną niepewnością. Podejście oparte na manifeście jest obiecujące, ponieważ definicje ról można edytować. Opiekunowie mogą sprawdzić, co ma robić planista, zmienić prompt przeglądu, dodać rolę dokumentacyjną właściwą dla projektu albo usunąć rolę, która nie przynosi pożytku. Jest to bliższe konwencjonalnemu dostosowywaniu projektu open source niż panelowi dostawcy, w którym zachowanie zmienia się bez lokalnego diffa. Pojawia się też praca utrzymaniowa. Pliki promptów są częścią zachowania systemu. Potrzebują testów, wersjonowania i przeglądu. Zmiana instrukcji agenta może mieć konsekwencje porównywalne ze zmianą handlera polecenia, zwłaszcza jeśli wpływa na moment wywoływania narzędzi albo ilość dołączanego kontekstu. Projekty wdrażające Spettro powinny przeglądać manifesty agentów z taką samą uwagą jak konfigurację CI i skrypty deweloperskie. ## Elastyczność dostawców pomaga, ale przenosi odpowiedzialność na operatora Dokumentacja projektu opisuje obsługę Anthropic, API zgodnych z OpenAI oraz lokalnych endpointów, takich jak LM Studio czy Ollama. Spettro reklamuje również routing dostawców, katalog modeli i ujednolicone poziomy rozumowania. To przydatne podczas eksperymentów: można porównać model hostowany z lokalnym, użyć tańszego modelu do eksploracji repozytorium albo pozostawić wrażliwy kod na wewnętrznym endpointcie, jeśli działa wystarczająco niezawodnie. Niezależność od dostawcy nie oznacza niezależności od modelu. Różne modele odmiennie interpretują narzędzia, limity kontekstu, ustrukturyzowane wyniki i instrukcje akceptacji. Prompt, który u jednego dostawcy prowadzi do ostrożnego planu, u innego może wygenerować płytkie podsumowanie. Model dobrze radzący sobie z krótką zmianą w Go może mieć trudności z dużym monorepozytorium. Runtime może ujednolicić polecenie takie jak `/thinking high`, ale nie uczyni modeli równoważnymi. Najlepsza metoda oceny polega na utrzymaniu zadania bez zmian. Użyj małego repozytorium testowego, zdefiniuj oczekiwane pliki i testy, a następnie wykonaj to samo zadanie z dwoma dostawcami. Zapisz, czy plan wskazuje właściwy kod, czy agent pyta przed użyciem narzędzi, czy końcowa łatka przechodzi testy i ile poprawek wymagała praca człowieka. To daje bardziej użyteczny wynik niż ocena interfejsu po jednej efektownej demonstracji. Jest również pytanie o zarządzanie danymi. Repozytorium podaje, że klucze są szyfrowane, a strona pokazuje wybór dostawców hostowanych i lokalnych, ale przed podłączeniem poświadczeń nadal trzeba przeczytać dokumentację konfiguracji i przechowywania. Należy ustalić, który proces może odczytać klucz, gdzie przechowywane są dane sesji, czy prompty i wyniki narzędzi są zapisywane oraz czy włączona funkcja webowa albo relay tworzy dodatkową ścieżkę danych. „Przynieś własny klucz” jest decyzją wdrożeniową, a nie pełną polityką prywatności. ## ACP czyni ze Spettro coś więcej niż ciekawostkę terminalową Spettro może działać jako agent Agent Client Protocol za pośrednictwem standardowego wejścia i wyjścia. Dokumentacja ACP podaje, że edytory takie jak Zed i wtyczki Neovim mogą sterować nim z natywnego interfejsu agenta, zachowując istniejące ustawienia dostawcy, modelu, uprawnień, manifestu i sandboxa. To praktyczna decyzja projektowa. Pozwala utrzymać politykę wykonania w jednym runtime’ie, a jednocześnie zmienić interfejs użytkownika. Ma to znaczenie, ponieważ narzędzia terminalowe często stają przed fałszywym wyborem. Mogą oferować mocny przepływ w wierszu poleceń, ale wymagać porzucenia edytora, albo głęboko integrować się z jednym edytorem i przejmować jego założenia. ACP tworzy możliwy szew między tymi sprawami. Spettro może pozostać runtime’em agenta, a edytor miejscem wyświetlania promptów, diffs i pytań. Ten szew jest również miejscem, w którym mogą ukrywać się błędy. Integracje z edytorami dodają tłumaczenie protokołu, obsługę cyklu życia, strumieniowanie wyników, anulowanie i monity uprawnień. Problem po stronie klienta może sprawić, że bezpieczna polityka będzie wyglądała na zepsutą, a niejasny interfejs może skłonić użytkownika do akceptacji czegoś bez zrozumienia zakresu. Wcześni użytkownicy powinni testować ACP z tymi samymi ograniczeniami co terminal i potwierdzić, że anulowanie rzeczywiście zatrzymuje operację w tle. Na razie najmocniejszy argument za ACP nie polega na tym, że zastępuje ono asystenta edytora. Chodzi o to, że ułatwia włączenie projektu do istniejącego przepływu bez wyrzucania zadeklarowanych kontroli runtime’u. To przewaga architektoniczna, którą warto obserwować, szczególnie jeśli protokół będzie wdrażać więcej klientów. ## Zdalne sterowanie i Telegram wymagają dodatkowej ostrożności Repozytorium opisuje pętlę zdalnego sterowania działającą na loopbacku oraz tryb, który może udostępnić płaszczyznę sterowania urządzeniom w sieci LAN. Dokumentuje także relay Telegrama. Funkcje te mogą być przydatne osobie, która chce obserwować lub prowadzić sesję z innego urządzenia, ale znacząco zmieniają model zagrożeń. Narzędzie terminalowe czytające wyłącznie lokalne wejście to jedno; narzędzie przyjmujące zdalne polecenia to coś innego. Bezpiecznym domyślnym ustawieniem jest pozostawienie funkcji zdalnych wyłączonych do czasu zrozumienia ich uwierzytelniania, adresu wiązania, bezpieczeństwa transportu i autoryzacji poleceń. „Loopback” jest węższy niż dostęp z LAN-u, ale nie zastępuje lektury implementacji. Do lokalnego endpointu webowego może nadal dotrzeć inny proces, rozszerzenie przeglądarki albo przekierowany port. Relay czatu wprowadza zewnętrzne konto, przechowywanie wiadomości, obsługę tokena bota i możliwość, że polecenie konwersacyjne zostanie zinterpretowane jako instrukcja modyfikacji repozytorium. Jeśli tryb zdalny jest konieczny, użyj projektu tymczasowego, dowiąż usługę do najmniejszego możliwego interfejsu, utrzymuj restrykcyjną politykę systemu plików i sprawdź dostępne polecenia przed połączeniem z prawdziwym checkoutem. Nie traktuj widocznej historii czatu jako śladu audytowego, chyba że projekt opisuje, jak rejestruje wywołania narzędzi, zdarzenia akceptacji i błędy. Nie jest to krytyka właściwa tylko dla Spettro. To ogólna zasada dla runtime’ów agentów: każda funkcja wygody zwiększająca osiągalność zasługuje na osobny przegląd bezpieczeństwa. Otwartość kodu sprawia, że taki przegląd jest możliwy, ale nie wykonuje go za ciebie. ## GPL-3.0 to znaczący wybór Repozytorium Spettro wskazuje licencję GPL-3.0. To istotnie różni się od liberalnych licencji używanych przez wiele bibliotek deweloperskich. Program można uruchamiać, analizować, modyfikować i udostępniać na warunkach GPL, ale organizacje planujące włączyć go do własnego, rozprowadzanego produktu muszą skonsultować prawne konsekwencje sposobu łączenia i dystrybucji kodu. Licencja pasuje także do deklarowanej pozycji projektu. Spettro nie jest wyłącznie SDK ukrytym za hostowaną usługą; repozytorium obejmuje runtime, prompty, skrypty instalacyjne i dokumentację. Silna licencja copyleft może pomóc zachować możliwość analizowania i redystrybuowania zmodyfikowanych wersji. Może też ograniczyć liczbę organizacji, które zechcą uczynić z niego komponent zamkniętego narzędzia komercyjnego. Nie należy wyciągać z licencji wniosków, których ona nie zawiera. GPL-3.0 nie gwarantuje wsparcia, czasu reakcji na problemy bezpieczeństwa, odtwarzalnych buildów ani stabilnego API. To pytania dotyczące zarządzania projektem i inżynierii wydań. Najnowsza strona wydań pokazywała v2.8.2, a README wymienia Go 1.26.1 lub nowsze do budowania ze źródeł. Wystarcza to, by uznać projekt za aktywny i szybko zmieniający się, ale nie wystarcza do potwierdzenia długoterminowej kompatybilności. ## Historia wydań mówi: wypróbuj, ale nie standaryzuj jeszcze Najnowsze otagowane wydanie wymienione na GitHubie, v2.8.2, opublikowano 4 października 2026 roku. Poprzednie v2.8.1 dodało animowane logo terminala, a v2.8.0 opublikowano 28 września. Widoczne tempo sugeruje projekt szybko przechodzący przez zmiany interfejsu i przepływu pracy. Dla wczesnego użytkownika, który chce szybko otrzymywać usprawnienia, może to być zaleta. Dla zespołów potrzebujących stabilnego zachowania na wielu maszynach będzie to niewygodne. Repozytorium nie pokazywało też liczby zgłoszeń ani pull requestów w podsumowaniu strony wydania w chwili sprawdzania, a strona główna wskazywała niewielką społeczność. Te sygnały należy interpretować ostrożnie; są migawką, a nie oceną jakości. Oznaczają jednak, że na wiele ważnych pytań trzeba odpowiadać przez lekturę kodu, a nie przez poleganie na latach raportów społeczności. Przed przyjęciem nowej wersji przypnij wydanie albo commit, zachowaj dotychczasowy binarny artefakt i uruchom stały test dymny. Powinien obejmować zaufanie do projektu, konfigurację dostawcy, generowanie planu, akceptację, kontrolowaną edycję pliku, wykonanie testów, wznowienie sesji i zamknięcie. Jeśli korzystasz z ACP, dodaj uruchamianie edytora, anulowanie i monity uprawnień. Jeśli korzystasz ze zdalnego sterowania, dodaj sprawdzenie uwierzytelniania i granic sieciowych. Mały harness testowy jest wart więcej niż duża demonstracja. Pozwala zauważyć, kiedy aktualizacja zależności zmienia powierzchnię poleceń, domyślny tryb uprawnień, strukturę promptów albo zachowanie trwałego zapisu. ## Kto powinien teraz wypróbować Spettro Spettro ma sens dla kilku konkretnych grup. Po pierwsze, dla programistów preferujących pracę w terminalu, którzy chcą eksperymentować z rolami agentów bez przywiązywania się do jednego dostawcy modeli. Możliwość podłączenia dostawców hostowanych lub lokalnych oraz inspekcji manifestu jest przydatna podczas porównań. Po drugie, dla opiekunów projektów open source zainteresowanych mechaniką nadzorowania agentów. Spettro jest na tyle małe, że można je czytać, napisano je w znanym języku i jasno pokazuje elementy przepływu, które większe narzędzia często ukrywają za granicą usługi. Współtwórcy mogą pracować nad promptami, adapterami dostawców, sandboxem, obsługą ACP, testami, dokumentacją albo inżynierią wydań. Po trzecie, dla zespołów budujących wewnętrzne prototypy, w których najważniejszy jest kontrolowalny wykonawca zadań, a nie dopracowana platforma korporacyjna. Ograniczony lokalny workspace bez poświadczeń może być bezpiecznym miejscem do sprawdzenia, czy przekazania plan-akceptacja poprawiają jakość przeglądu. To słabe dopasowanie dla zespołu szukającego dojrzałego, wspieranego produktu flotowego z gwarantowaną zgodnością aktualizacji. Nie jest też dobrym pierwszym wyborem do nadzorowanych zmian w infrastrukturze produkcyjnej, repozytoriach zawierających wrażliwe poświadczenia ani zadań, których ukończenia nie da się automatycznie sprawdzić. ## Praktyczny plan oceny Użyteczna próba może zmieścić się w jednym popołudniu, jeśli zakres pozostanie mały. Zacznij od świeżego repozytorium z niewielkim programem, nieudanym testem i krótkim README. Zbuduj Spettro z przypiętego wydania albo użyj artefaktu wydania, a następnie przeczytaj dokumentację konfiguracji i uruchomienia projektu. Nie zaczynaj od prawdziwej aplikacji. Ustaw system plików na tylko do odczytu, a sieć na `none`. Poproś agenta planującego o opis sposobu naprawy nieudanego testu. Sprawdź, czy wskazuje właściwy plik i czy nie twierdzi, że coś zmienił. Następnie przełącz się na workspace ograniczony do repozytorium tymczasowego i zaakceptuj najmniejszą możliwą edycję. Wykonaj to samo zadanie z drugim dostawcą albo lokalnym endpointem. Porównaj plan, sekwencję narzędzi, końcowy diff, testy i liczbę poprawek. Spróbuj przerwać działanie. Zamknij terminal i wznów sesję. Sprawdź, co zostało zapisane. Jeśli używasz edytora przez ACP, powtórz tam testy akceptacji i anulowania. Dopiero po tych kontrolach dodaj prawdziwe, ale niewrażliwe repozytorium. Trzymaj agenta z dala od poświadczeń wdrożeniowych, tokenów publikowania pakietów i osobistej konfiguracji. Użyj osobnego worktree albo tymczasowej gałęzi. Zapisz wersję, model, dostawcę, ustawienia uprawnień i instrukcje repozytorium, aby późniejszy wynik można było odtworzyć. Ta metoda dostarcza też projektowi użytecznej informacji zwrotnej. Zgłoszenie błędu zawierające przypiętą wersję, małą reprodukcję, tryb uprawnień, dostawcę oraz oczekiwane i zaobserwowane wywołanie narzędzia jest znacznie cenniejsze niż informacja, że agent zachowywał się dziwnie. ## Co obserwować dalej Kolejne istotne testy Spettro nie polegają na dopisywaniu następnej listy poleceń. Chodzi o stabilność i dowody. Czy projekt utrzyma spójne znaczenie uprawnień podczas dodawania funkcji? Czy uczyni stan sesji możliwym do sprawdzenia i przenoszenia? Czy integracja ACP zachowa te same gwarancje akceptacji co interfejs terminalowy? Czy opiekunowie opiszą, jak przechowywane są poświadczenia, prompty, wyniki narzędzi i zdalne relaye? Czy współtwórca będzie mógł odtworzyć wydanie ze źródeł i zrozumieć, które zmiany wpływają na zachowanie agenta? Otwartoźródłowy charakter projektu sprawia, że na te pytania można odpowiadać publicznie. Niewielki rozmiar ułatwia współtworzenie. Obecna dojrzałość oznacza, że odpowiedzi nie są jeszcze ustalone. Właśnie dlatego Spettro zasługuje na obserwowanie: nie jako gotowy zamiennik każdego asystenta kodującego, lecz jako konkretny eksperyment z uczynieniem pracy agenta czytelną. Najbardziej użyteczną ideę Spettro da się zachować w prostym zdaniu: autonomia powinna być otoczona jawnymi granicami. Plan powinien być widoczny przed wykonaniem. Rola powinna mieć określone zadanie. Wywołanie narzędzia powinno dziedziczyć politykę. Sesję powinno dać się wznowić bez zamieniania jej w zagadkę. Oprogramowanie nadal potrzebuje utwardzenia, dokumentacji, przeglądu bezpieczeństwa i większej grupy niezależnych użytkowników. Do tego czasu traktuj je jak obiecujące laboratorium i utrzymuj laboratorium w izolacji.