Claude Code v2.1.314 wprowadza wyraźniejsze granice zautomatyzowanej pracy
Anthropic wydał Claude Code v2.1.314 30 października, dodając ograniczenia zapisu plików działające we wszystkich trybach uprawnień, a także mechanizmy kontroli routowania dla przedsiębiorstw. Aktualizacja rozszerza również podsumowywanie nieaktywnych rozmów na VS Code i kartę Code w Claude Desktop. Łącznie zmiany te dotyczą praktycznego napięcia: programiści chcą, aby agenci programistyczni kontynuowali pracę, podczas gdy administratorzy potrzebują granic, które pozostają skuteczne w trakcie automatycznego działania.
Wydanie zwiększa presję na zespoły zarządzające dostępem agentów, połączeniami chmurowymi i długimi sesjami programistycznymi. Przyznanie agentowi zgody na kontynuowanie pracy nie rozstrzyga, które pliki powinien zmienić ani do jakiej infrastruktury powinien kierować żądania. Decyzje te wymagają mechanizmów kontroli wykraczających poza interpretację zadania przez model.
GitHub Copilot stanowi użyteczne porównanie, ponieważ jego lokalne sandboxing również oddziela automatyczne wykonywanie od nieograniczonego dostępu do maszyny. Aktualizacja Anthropic wpisuje się w tę operacyjną dyskusję. Jej znaczenie wynika z tego, jak współdziałają uprawnienia, odzyskiwanie po błędach i zarządzanie rozmową, a nie z jakiegokolwiek ogłoszonego wzrostu zdolności programistycznych.
Co zmienia Claude Code v2.1.314
Aktualizacja dodaje mechanizmy kontroli miejsca wykonywania pracy oraz sposobu kontynuowania przerwanej pracy.
Zgodnie z oficjalnymi informacjami o wydaniu, permissions.blockWritesOutsideWorkingDirectories powoduje, że narzędzia Write, Edit i NotebookEdit odrzucają ścieżki poza katalogami roboczymi we wszystkich trybach uprawnień. Brama dodaje opcjonalne ograniczenia groups dla upstreamów, także podczas przełączania awaryjnego. Integracja z Bedrock dodaje również guardrail_trace, identyfikując uruchomione filtry bez zapisywania dopasowanego tekstu.
Zmiany te dotyczą różnych granic. Ograniczenia plików odnoszą się do lokalnych modyfikacji. Routowanie przez bramę dotyczy tego, dokąd trafiają żądania modelu. Śledzenie filtrów dotyczy tego, co administratorzy mogą później sprawdzić. Traktowanie ich jako odrębnych mechanizmów kontroli pomaga wyjaśnić zarówno ich wartość, jak i ograniczenia.
Katalog roboczy to folder uwzględniony w dozwolonym obszarze roboczym sesji. Nowe ustawienie nadaje tej granicy wyraźne znaczenie dla wskazanych narzędzi plikowych. Polecenie ukończenia zadania samo w sobie nie rozszerza tego zakresu.
Rozważmy przykładowe zadanie utrzymaniowe dotyczące repozytorium i sąsiedniego folderu zawierającego inny projekt. Proponowana zmiana mogłaby mieć sens techniczny w obu folderach. To, czy agent powinien ją wykonać, pozostaje jednak kwestią autoryzacji, odrębną od tego, czy zmiana się skompiluje.
Granica katalogu może więc przerwać uzasadnione zadanie. Takie przerwanie dostarcza użytecznej informacji: albo obszar roboczy wymaga świadomego rozszerzenia, albo proponowana edycja wykracza poza przydzielone zadanie. Ciche traktowanie sąsiednich plików jako dostępnych ukrywałoby tę decyzję.
Zmiany w bramie stosują to samo ogólne rozumowanie do infrastruktury. Upstream to połączenie z dostawcą, przez które brama wysyła żądania modelu. Dostęp programisty do bramy nie musi oznaczać uprawnienia do korzystania z każdego upstreamu działającego za nią.
Przełączanie awaryjne, czyli przejście na inne połączenie po awarii, sprawia, że rozróżnienie to jest szczególnie istotne. Odzyskiwanie po błędzie powinno zachowywać wymagania dostępu. W przeciwnym razie moment niedostępności usługi staje się jednocześnie momentem zmiany polityki routowania.
Kompresja nieaktywnych sesji dotyczy ciągłości z innej strony. Kompresja podsumowuje historię rozmowy, zastępując dłuższy kontekst roboczy krótszą reprezentacją. Wydanie rozszerza to zachowanie na obsługiwane sesje w edytorach i aplikacji desktopowej, gdy długie rozmowy pozostają nieużywane.
Nie należy odczytywać tych funkcji jako dowodu wyższej jakości kodu. Ich deklarowany cel dotyczy działania: ograniczania akcji, zachowywania wymagań routowania, usprawniania diagnostyki i ułatwiania kontynuowania sesji. Ich praktyczna wartość zależy od tego, czy zachowania te utrzymują się przy realistycznych obciążeniach.
Administratorzy dziedziczą decyzje stojące za automatyzacją
Bardziej autonomiczne wykonywanie zwiększa znaczenie jednoznacznych decyzji administracyjnych.
Programista zazwyczaj ocenia asystenta programistycznego przez pryzmat bezpośredniego zadania. Czy zidentyfikował właściwy plik, wprowadził żądaną zmianę i wyjaśnił wynik? Administrator musi uwzględnić warunki otaczające tę pracę.
Warunki te obejmują zakres obszaru roboczego, kwalifikowalność dostawców, ustawienia organizacyjne i obsługę awarii. Udana poprawka nie odpowiada na pytanie, czy żądanie wykorzystało zatwierdzone połączenie. Ukończona sesja nie dowodzi, że każda podjęta próba działania pozostała zgodna z polityką.
Architektura bramy wyjaśnia podział odpowiedzialności. Anthropic opisuje usługę hostowaną samodzielnie, która łączy programistów z dostawcami modeli chmurowych poprzez firmowe logowanie. Brama przechowuje poświadczenia upstreamów oraz stosuje mechanizmy kontroli dostępu i zarządzane ustawienia.
Dostawca tożsamości, czyli IdP, to firmowy system dostarczający tożsamości logowania i informacje o przynależności do grup. Routowanie oparte na grupach sprawia, że te informacje o tożsamości stają się częścią ścieżki żądania. Jego użyteczność zależy zatem od utrzymywania przez organizację znaczących grup.
Przykładowo wyobraźmy sobie przedsiębiorstwo rozdzielające eksperymentalny zespół inżynieryjny od pracowników obsługujących projekty klientów objęte ograniczeniami. Oba zespoły korzystają z tego samego interfejsu programistycznego. Ich dozwolone połączenia z dostawcami różnią się, ponieważ ich praca podlega odmiennym wewnętrznym wymaganiom.
To przykładowy scenariusz, a nie udokumentowane wdrożenie u klienta. Pokazuje, dlaczego wspólny interfejs nie eliminuje potrzeby odrębnych zasad dostępu. Administratorzy nadal muszą przekładać decyzje organizacyjne na ustawienia, które system może egzekwować.
To przełożenie tworzy pracę utrzymaniową. Nazwy grup się zmieniają, pracownicy przechodzą między zespołami, wdrożenia dostawców ewoluują, a tymczasowe wyjątki dostępu się kumulują. Funkcja routowania zapewnia mechanizm; nie decyduje, które granice organizacyjne zasługują na egzekwowanie.
Bezpośrednia presja spada na zespoły inżynierii platformowej i infrastruktury programistycznej. Muszą zapewnić wygodę rutynowych przepływów pracy, jednocześnie dbając o to, by wyjątki pozostawały świadome. Zespoły bezpieczeństwa potrzebują wystarczającej widoczności, aby rozumieć awarie, bez przekształcania każdego dochodzenia wsparcia w nieograniczony dostęp do treści rozmów.
Programiści również odczuwają skutki. Żądanie, które wcześniej byłoby kontynuowane, może teraz zatrzymać się na granicy katalogu. Połączenie z dostawcą dostępne dla kolegi może być dla nich niedostępne. Jasne wyjaśnienia są ważne, ponieważ w przeciwnym razie celowe ograniczenia wyglądają jak arbitralne awarie produktu.
Praktyczną odpowiedzią jest zdefiniowanie oczekiwanego zachowania przed diagnozowaniem nieoczekiwanego zachowania. Zespoły muszą wiedzieć, które foldery należą do zadania i które połączenia z dostawcami należą do danej grupy. Bez tych oczekiwań nawet poprawne egzekwowanie zasad może być trudne do zinterpretowania.
Przesuwa to część dyskusji o wdrożeniu w stronę odpowiedzialności operacyjnej. Ktoś musi być właścicielem polityki, wyjaśniać jej konsekwencje i przeglądać zmiany. Zainstalowanie nowszego klienta zapewnia możliwości, ale nie kończy tej pracy organizacyjnej.
Uprawnienia do plików i sandboxing chronią różne granice
Ograniczenie narzędzi plikowych należy oceniać oddzielnie od ochrony procesów powłoki.
Brzmienie ograniczenia zapisu ma znaczenie. Anthropic wskazuje konkretne narzędzia edycji i podaje, że granica obowiązuje we wszystkich trybach uprawnień. Stanowi to użyteczne twierdzenie dotyczące tych narzędzi, a nie uniwersalne twierdzenie o każdym możliwym zapisie.
Polecenie powłoki również może modyfikować pliki. Może to zrobić także skrypt, instalator zależności lub proces uruchomiony przez narzędzie programistyczne. Organizacja oceniająca ochronę systemu plików musi rozumieć, które ścieżki wykonania obejmuje każdy mechanizm kontroli.
Dokumentacja Bash sandbox Anthropic opisuje granicę systemu operacyjnego wokół poleceń powłoki i ich procesów potomnych. Odróżnia tę granicę od decyzji dotyczących uprawnień. Sandbox obejmuje wykonywanie w powłoce, podczas gdy inne narzędzia wymagają własnych odpowiednich mechanizmów kontroli.
To rozróżnienie jest w praktyce proste. Obsługa uprawnień decyduje, czy działanie zostanie wykonane. Izolacja ogranicza zasoby, do których może dotrzeć wykonywany proces. Oba elementy wpływają na bezpieczeństwo, ale działają w różnych punktach.
To rozdzielenie pomaga uniknąć mylących wniosków dotyczących uprawnień Claude Code wyjaśnianych przez pojedyncze ustawienie. Odrzucone żądanie Edit pokazuje działanie konkretnego ograniczenia. Nie ustala jednak zachowania każdego skryptu czy zewnętrznej integracji dostępnej w sesji.
Podobnie pomyślne polecenie powłoki nie musi przeczyć zasadzie dotyczącej narzędzi plikowych. Istotne pytania dotyczą jego środowiska wykonania, obowiązującej polityki sandboxa i autoryzowanych ścieżek. Te szczegóły określają, czy zaobserwowane zachowanie odpowiada zamierzonej granicy.
Użyteczna ocena powinna zatem rozróżniać bezpośrednią edycję od modyfikacji wykonywanych przez polecenia. Powinna także odróżniać zwykłe działanie od wznowionej pracy i alternatywnych środowisk wykonawczych. Są to proponowane kategorie oceny, a nie twierdzenia o testach przeprowadzonych na potrzeby tego artykułu.
Kontekst konkurencyjny wzmacnia tę kwestię. GitHub ogłosił lokalne sandboxing jako ogólnie dostępne 7 października 2026 roku. Opis obejmuje ograniczony dostęp do systemu plików, sieci i poświadczeń w obsługiwanych środowiskach Copilot.
GitHub podaje również, że polityki sandboxa są stosowane niezależnie od użytego modelu. To użyteczne porównanie, ponieważ umieszcza egzekwowanie zasad w systemie wykonawczym. Wybór modelu i określenie jego dozwolonych zasobów to odrębne decyzje produktowe.
Ogłoszenia nie ustanawiają identycznego zakresu ochrony między Claude Code a Copilot. Różnią się ich środowiska, ustawienia domyślne i obsługiwane integracje. Uczciwe porównanie bada rzeczywistą ścieżkę wykonania zadania, zamiast zestawiać nazwy funkcji.
Dla kupujących szerokie etykiety są przez to mniej informacyjne niż konkretne pytania. Który proces otrzymuje poświadczenia? Które narzędzia działają w izolacji? Kto może rozszerzyć politykę? Co dzieje się po zablokowanej operacji?
Dla programistów korzyścią jest przewidywalność. Wyraźna granica ułatwia zrozumienie, czy awaria wymaga zmiany zadania, poprawienia konfiguracji czy wystąpienia o dostęp. Niejasne założenia dotyczące bezpieczeństwa agentów pozostawiają te możliwości splątane.
Najmocniejsza interpretacja tego wydania jest zatem konkretna. Anthropic dodaje kolejną egzekwowalną granicę dla wskazanych narzędzi. Ocena całego obszaru roboczego nadal wymaga zrozumienia otaczającego środowiska wykonawczego.
Odzyskiwanie przez bramę musi zachowywać zasady dostępu
Odzyskiwanie po awarii jest użyteczne tylko wtedy, gdy respektuje warunki przypisane do pierwotnego żądania.
Awarie dostawców stwarzają trudny wybór operacyjny. Kontynuowanie pracy przez inne połączenie może zachować produktywność. Może również zmienić miejsce przepływu informacji, stosowane poświadczenia lub zasady organizacyjne regulujące żądanie.
Ograniczenie grup upstreamów rozwiązuje część tego problemu. Uwzględnienie przełączania awaryjnego oznacza, że wymagania dostępu pozostają istotne przy zmianie routowania. Ważną zasadą jest ciągłość autoryzacji obok ciągłości usługi.
Wyobraźmy sobie żądanie kwalifikujące się do połączenia preferowanego przez wewnętrzny zespół. To połączenie staje się niedostępne, podczas gdy inny skonfigurowany upstream nadal działa prawidłowo. Sama dostępność nie powinna przesądzać o tym, że programista może użyć alternatywy.
Ten przykład ilustruje kwestię polityki, a nie opisuje incydentu produkcyjnego. Oczekiwany wynik zależy od konfiguracji organizacji. Świadoma odmowa może być właściwym rezultatem, gdy nie istnieje żadna kwalifikująca się alternatywa.
Tworzy to kompromis, który administratorzy powinni uwzględnić. Bardziej rygorystyczne ograniczenia routingu mogą zmniejszyć liczbę ścieżek odzyskiwania. Zespoły nie mogą zakładać, że nieograniczony failover i wąsko zdefiniowany dostęp do dostawców zawsze zapewnią taką samą dostępność.
Dokumentacja Anthropic dotycząca konfiguracji gatewaya podkreśla również system tożsamości stojący za decyzjami polityk. Dopasowywanie grup zależy od dostarczonych claims, a udokumentowane reguły dopasowywania uwzględniają wielkość liter. Gateway opiera się na tych danych tożsamości podczas oceny dostępu.
Claim to informacja o tożsamości przenoszona w tokenie logowania. Nieprawidłowe lub niepełne informacje o grupie mogą zatem stać się problemem routingu. Samo doświadczenie po stronie klienta może nie ujawnić, czy przyczyna leży w konfiguracji tożsamości, czy w dostępności dostawcy.
W tym miejscu diagnostyka nabiera znaczenia. Zespół wsparcia musi odróżnić decyzję o dostępie od zerwanego połączenia. W przeciwnym razie rozwiązywanie problemów może prowadzić do niepotrzebnych zmian konfiguracji lub presji na rozszerzenie uprawnień.
Dodanie śledzenia Bedrock stanowi kolejny przykład selektywnej widoczności. Zidentyfikowanie uruchomionego filtra może pomóc wyjaśnić odrzucone żądanie, jednocześnie nie ujawniając tekstu, który dopasował się do filtra. Daje operatorom kategorię wyjaśnienia bez automatycznego ujawniania źródłowego fragmentu.
To ograniczona obietnica diagnostyczna. Identyfikator filtra nie dowodzi, że odmowa była prawidłowa. Nie pokazuje, czy filtr został odpowiednio skonfigurowany dla konkretnego przepływu pracy inżynieryjnej.
Administratorzy mogą nadal potrzebować zatwierdzonego procesu odtwarzania problemu, aby badać sporne wyniki. Programiści potrzebują sposobu zgłaszania uzasadnionej pracy, która wielokrotnie kończy się niepowodzeniem. Te procesy organizacyjne pozostają konieczne, nawet gdy logi stają się bardziej informacyjne.
Istnieje też szersze rozróżnienie dotyczące prywatności. Pominięcie dopasowanego tekstu w tym śladzie nie określa zawartości każdego innego systemu logowania lub monitorowania. Zespoły powinny oceniać całe wdrożenie, zamiast rozszerzać gwarancję jednej funkcji na całe środowisko.
Celem operacyjnym jest wynik możliwy do wyjaśnienia. Żądanie powinno albo trafić do kwalifikującego się połączenia, albo zakończyć się błędem wskazującym odpowiednie ograniczenie. Powtarzane próby bez tej jasności pochłaniają czas, pozostawiając podstawową decyzję nierozstrzygniętą.
Kompaktowanie bezczynnych sesji zamienia pełną historię na krótszy kontekst roboczy
Podsumowania rozmów poprawiają ciągłość tylko wtedy, gdy zachowują istotne decyzje.
Rozszerzenie dla edytora i desktopu przybliża zarządzanie rozmowami do miejsca, w którym pracuje wielu programistów. Duża sesja może pozostawać bezczynna, gdy ktoś uczestniczy w spotkaniu, przegląda zmiany lub przełącza projekty. Powrót do niej rodzi pytania o zachowany kontekst i narzut przetwarzania.
Token to jednostka tekstu przetwarzana przez model. Wydanie opisuje kompaktowanie bezczynnych rozmów osiągających co najmniej 200 000 tokenów. Cache promptów przechowuje ponownie używalny przetworzony kontekst; gdy taki cache wygasa, ponowne wysłanie długiej rozmowy ma inne konsekwencje operacyjne.
Ustawienia kompaktowania bezczynnych sesji Anthropic opisują dodatkowe warunki kwalifikacji. Obejmują one włączone automatyczne kompaktowanie, jednogodzinny cache promptów, dostęp do flag funkcji, wystarczający rozmiar rozmowy oraz aktywny komputer w okresie bezczynności.
Warunki te mają znaczenie, ponieważ sama nieaktywność nie gwarantuje podsumowania. Programiści porównujący sesje muszą uwzględniać swoje środowisko i ustawienia. Zaobserwowana różnica nie wskazuje automatycznie na niespójne działanie.
Podstawowym kompromisem jest kompresja informacji. Krótsze podsumowanie może zawierać główny kierunek zadania, jednocześnie pomijając szczegóły z pierwotnej wymiany. To, czy takie pominięcie ma znaczenie, zależy od wymagań kolejnego zadania.
Rozważmy przykładową dyskusję o migracji. Rozmowa obejmuje wybrane podejście, odrzucone alternatywy, wyjątek związany ze zgodnością oraz powód zachowania nietypowego działania. Podsumowanie może zachować wybrane podejście, lecz mniej precyzyjnie wyrazić wyjątek.
Ryzyko w tym scenariuszu dotyczy wierności decyzjom. Płynna kontynuacja nie jest wystarczającym dowodem, że asystent zachował każde ważne ograniczenie. Istotne pytanie brzmi, czy jego następne działanie nadal jest zgodne z przyjętymi decyzjami technicznymi.
Nie dowodzi to, że implementacja Anthropic gubi te szczegóły. Publiczny opis funkcji nie przedstawia benchmarku odpowiadającego na to pytanie. Pozostaje to kwestią ewaluacji dla zespołów, których praca zależy od dokładnego kontekstu historycznego.
Dokumentacja oferuje sposób wyłączenia kompaktowania bezczynnych sesji. Daje to użytkownikom wybór dotyczący zachowania sesji, z uwzględnieniem obowiązujących ustawień. Sprawia też, że kompromis ten zespoły mogą omawiać wprost, zamiast odkrywać go przez nieporozumienia.
W złożonej pracy trwałe rejestry projektowe służą innemu celowi niż kontekst rozmowy. Zweryfikowane wymaganie, decyzja architektoniczna lub nierozwiązana blokada powinny pozostać dostępne poza pojedynczym czatem. Podsumowanie nie powinno stać się jedynym zapisem tego, dlaczego zmiana została zatwierdzona.
Przeszukiwalna baza wiedzy może wspierać taki podział, utrzymując dokumenty techniczne dostępne do późniejszego wglądu. Użyteczna zasada nie zależy od konkretnego procesu prowadzenia notatek: autorytatywne decyzje należy zachowywać poza przejściowym stanem rozmowy.
W przypadku Claude Code v2.1.314 bezpośrednie pytanie dotyczy tego, jak powracające sesje zachowują się w rzeczywistych zadaniach inżynieryjnych. Istotne obserwacje obejmują zachowane ograniczenia, wymagane ponowne sformułowania oraz to, czy wznowiona praca pozostaje zgodna ze zweryfikowanymi wymaganiami.
Wydanie nie daje podstaw do przypisania tej funkcji mierzalnego wzrostu produktywności. Jej wartość będzie zależeć od rozmiaru rozmowy, wzorców przerw i złożoności zadania. Krótszy kontekst roboczy może pomagać, lecz jego jakość decyduje o tym, czy ta pomoc przetrwa kolejną edycję.
Na co zwrócić uwagę po aktualizacji
Najmocniejsze dowody będą wynikać ze spójności granic, możliwości odzyskania po awariach i wiernej kontynuacji sesji.
Pierwszym sygnałem jest egzekwowanie ograniczeń katalogów we wszystkich obsługiwanych trybach uprawnień. Kolejna dokumentacja i powtarzalne raporty powinny wyjaśnić, jak nowe ograniczenie narzędzi plikowych zachowuje się w zwykłych i wznowionych przepływach pracy. Spójne wyniki wzmocniłyby zaufanie do deklarowanego zakresu tego ustawienia.
Dowody niewyjaśnionych wyjątków osłabiłyby to zaufanie. Raporty powinny odróżniać nazwane narzędzie edycyjne od wykonywania poleceń powłoki lub zewnętrznej integracji. Bez tego rozróżnienia użyteczna obserwacja może stać się nieprecyzyjnym twierdzeniem o całym modelu ochrony.
Drugim sygnałem jest zachowanie gatewaya podczas awarii. Administratorzy powinni obserwować, czy ograniczenia dostępu pozostają zrozumiałe, gdy upstream staje się niedostępny. Jasna odmowa za pośrednictwem nieautoryzowanej alternatywy wspiera cel wydania, jakim jest zachowanie polityk.
Nieoczekiwany routing lub niejednoznaczne zachowanie ponawiania prób wskazywałyby na odwrotną sytuację. Jakość diagnostyki ma tu znaczenie, ponieważ organizacje muszą identyfikować warstwę, w której występuje problem. Informacje o tożsamości, konfiguracja routingu, dostępność dostawcy i filtrowanie treści wymagają różnych reakcji.
Trzecim sygnałem jest jakość wznowionych rozmów po kompaktowaniu bezczynnych sesji. Znacząca obserwacja dotyczy tego, czy asystent zachowuje wymagania zadania i wcześniejsze decyzje. Krótszy kontekst, któremu towarzyszą powtarzane korekty, zmniejszałby praktyczną korzyść.
Użyteczne raporty opiszą zadanie i brakujące ograniczenie bez ujawniania wrażliwej treści rozmowy. Ogólne wrażenia dotyczące szybkości lub wygody mogą uzupełniać te dowody. Nie mogą jednak dowieść, że podsumowanie zachowało informacje potrzebne do konkretnej zmiany.
Sygnały te łączy standard operacyjny: system powinien czynić swoje granice i adaptacje zrozumiałymi. Programista musi wiedzieć, kiedy dostęp został odmówiony, kiedy routing był ograniczony i kiedy wcześniejszy kontekst został podsumowany. Administratorzy potrzebują odpowiednich dowodów do prowadzenia dochodzeń.
Ten standard pomaga również zachować właściwą perspektywę wobec wydania. Kontrole korporacyjne Claude Code zasługują na ocenę poprzez konkretne przepływy pracy, a nie szerokie twierdzenia o gotowości. Funkcja może być użyteczna w ramach udokumentowanego zakresu, pozostawiając inne pytania dotyczące wdrożenia bez odpowiedzi.
Organizacje rozważające Claude Code v2.1.314 powinny zacząć od reprezentatywnego zadania inżynieryjnego i jasno określonych oczekiwań. Należy wskazać autoryzowany obszar roboczy, kwalifikujące się połączenia z dostawcami oraz decyzje techniczne, które sesja musi zachować. Następnie trzeba ocenić, czy uzyskane zachowanie odpowiada tym oczekiwaniom.
Ocena powinna być bliska codziennej pracy: zmiana w repozytorium, przerwa w działaniu dostawcy oraz powrót do długiej rozmowy po przerwie. Należy rejestrować nieoczekiwane wyniki z wystarczającym kontekstem, aby odróżnić zamierzone egzekwowanie zasad od awarii. Zaakceptowane wymagania należy zachować w trwałym dokumencie, aby późniejsi recenzenci mogli porównać działania z tym samym źródłem. Te obserwacje powinny posłużyć do podjęcia decyzji, czy szersze wdrożenie jest uzasadnione i które kwestie konfiguracji pozostają otwarte. Użyteczne pytanie jest konkretne: czy zaktualizowany agent wykonuje autoryzowaną pracę, zachowując granice i decyzje, od których zależy Twój zespół?
