Claude Code v2.1.304 Wyraźniej Określa Decyzje Dotyczące Uprawnień

Claude Code v2.1.304 od Anthropic wprowadza wyraźniejsze granice uprawnień, jednocześnie rozszerzając konfigurację z przewodnikiem dla zautomatyzowanej pracy. Zmiany dotyczą praktycznego napięcia: programiści chcą mniej przerw, ale zespoły nadal muszą rozumieć, kto autoryzował daną czynność.

Aktualizacja zwraca uwagę na mechanizmy otaczające asystenta AI do programowania, w tym rozszerzenia, decyzje zatwierdzające i ustawienia wdrożeniowe. Jej znaczenie polega na ułatwieniu kontroli tych mechanizmów, a nie na ogłoszeniu nowej miary wydajności programowania.

GitHub Copilot stanowi użyteczne porównanie, ponieważ również łączy delegowaną pracę z kontrolami wykonania. W przypadku tych produktów praktyczne pytanie wykracza poza to, czy agent realizuje zadanie. Zespoły muszą wiedzieć, które granice zostały zachowane podczas jego pracy.

Co Zmienia Claude Code v2.1.304

Informacje o wydaniu Anthropic z 19 października opisują kilka powiązanych dodatków. Powiadomienie w transkrypcji identyfikuje zdarzenie i wtyczkę, gdy uruchomiona wcześniej wtyczka pomija hook moda. Mod jest rozszerzeniem; hook to wywołanie zwrotne uruchamiane przez zdarzenie.

Odpowiedź tool.check moda akceptuje teraz decider: "person". Tylko okno dialogowe uprawnień lub callback hosta może zatwierdzić takie żądanie. Gdy nie można nikogo zapytać, Claude Code odrzuca je z uzasadnieniem moda.

Odpowiednie zdarzenie zyskuje również e.isReadOnly, wskazujące wywołanie narzędzia tylko do odczytu. Tymczasem /auto-mode-setup odczytuje informacje o projekcie i ostatnich sesjach, aby dostosować tryb auto. Obsługuje teraz Bedrock, Vertex, Foundry, bramę aplikacji Claude oraz sesje z wyłączoną telemetrią.

Kolejny dodatek, /claude-api managed-agents-secure, porównuje ustawienia agenta Managed Agents z opublikowanymi przez Anthropic wytycznymi bezpieczeństwa, nie zmieniając ich. Managed Agents to hostowana infrastruktura agentowa Anthropic. Nazwy tych poleceń opisują funkcje produktu, a nie czynności wymagane do zrozumienia aktualizacji.

Wspólnym motywem jest bardziej jednoznaczna informacja o decyzjach, wykonaniu i konfiguracji.

Te dodatki dotyczą różnych momentów przepływu pracy agenta. Część odnosi się do decyzji przed działaniem. Inne dotyczą wyjaśnienia dostępnego później lub ustawień otaczających całą sesję.

To rozróżnienie ma znaczenie, ponieważ wydanie może poprawiać widoczność bez zmiany każdej podstawowej reguły egzekwowania. Jaśniejsze wyjaśnienie pomaga ludziom analizować zachowanie, lecz czytelnicy nie powinni traktować każdego dodatku diagnostycznego jako nowo egzekwowanego ograniczenia.

Ta sama ostrożność dotyczy dostępności. Szerszy dostęp do funkcji konfiguracji z przewodnikiem nie oznacza identycznego zachowania dla każdego modelu, polityki organizacyjnej czy sposobu wdrożenia. Warunki te wymagają własnej dokumentacji.

Dlatego dla programistów użyteczna interpretacja jest konkretna. Ta aktualizacja ujawnia więcej szczegółów na wybranych granicach. Nie zapewnia ogólnej gwarancji obejmującej każde rozszerzenie, integrację i środowisko.

Rozważmy hipotetyczny zespół badający nieoczekiwane zatwierdzenie. Zespół musi rozdzielić proponowaną czynność, decyzję polityki oraz komponent odpowiedzialny za tę decyzję. W przeciwnym razie pomyślnie wykonane zadanie może ukrywać niejasną ścieżkę autoryzacji.

Wydanie skupione na tych rozróżnieniach zasługuje na uwagę nawet bez głośnego benchmarku. W przypadku oprogramowania operacyjnego wyjaśnienie, dlaczego coś się wydarzyło, może być równie istotne jak przyspieszenie pomyślnego przebiegu.

Kolejne pytanie dotyczy tego, kto musi przekształcić dodatkowe informacje w skuteczną praktykę pracy. Ta odpowiedzialność w dużej mierze spoczywa na osobach utrzymujących rozszerzenia i współdzielone środowiska programistyczne.

Autorzy Rozszerzeń Stają Przed Bardziej Jednoznacznym Kontraktem Zatwierdzania

Asystent AI do programowania rzadko działa poprzez pojedynczy komponent. Programiści mogą dodawać reguły projektu, rozszerzenia, narzędzia zewnętrzne i specyficzną dla aplikacji obsługę zatwierdzeń. Każda warstwa wprowadza kolejne miejsce, w którym oczekiwania mogą się rozbiegać.

Reguły uprawnień Anthropic już rozróżniają typy narzędzi i obsługują zarządzane polityki. Dokumentacja oddziela również decyzje dotyczące uprawnień od sandboxingu, który ogranicza środowisko, w którym wykonywane są działania.

To rozdzielenie zapewnia kluczowy kontekst. Zatwierdzenie odpowiada na pytanie, czy działanie powinno zostać wykonane zgodnie z polityką. Granica wykonania ogranicza to, do czego może dotrzeć uruchomione działanie. Żadne z tych pytań nie daje pełnej odpowiedzi na drugie.

Autorzy rozszerzeń muszą przekazywać znaczenie decyzji równie starannie jak jej wynik.

Dla opiekuna rozszerzenia binarny wynik powodzenia może pozostawiać zbyt wiele niewyjaśnionych kwestii. Narzędzie może zostać uruchomione, ponieważ zatwierdził je człowiek, ponieważ pozwoliła na to istniejąca reguła albo ponieważ inne mechanizmy rozstrzygnęły żądanie.

Te ścieżki niosą różne konsekwencje dla firmy analizującej proces programistyczny. Jeżeli przepływ pracy obiecuje kontrolę człowieka, samo automatyczne ukończenie nie może potwierdzać, że obietnica została spełniona.

Tworzy to konkretny ciężar utrzymaniowy. Dokumentacja rozszerzenia, etykiety interfejsu i komunikaty o błędach powinny opisywać ten sam kontrakt zatwierdzania. W przeciwnym razie użytkownicy muszą wnioskować o polityce na podstawie zachowania podczas przerwanego zadania.

Użytecznym hipotetycznym przykładem jest wewnętrzna integracja wdrożeniowa. Organizacja może zezwalać na automatyczne przygotowanie, jednocześnie rezerwując publikację dla upoważnionego operatora. Integracja musi zachować to rozróżnienie po osadzeniu wewnątrz asystenta.

Istotnym rezultatem jest zrozumiała porażka, podobnie jak zrozumiały sukces. Zablokowany przepływ pracy powinien wyjaśniać, która decyzja pozostaje nierozstrzygnięta. Bez tego wyjaśnienia użytkownicy mogą pomylić zamierzoną granicę z uszkodzoną integracją.

Dla twórców aplikacji interfejs również staje się częścią projektu polityki. Aplikacja hosta, czyli oprogramowanie osadzające asystenta, musi przedstawiać żądania zatwierdzenia w sposób zrozumiały dla użytkowników.

Ekran zatwierdzenia, który pomija cel lub konsekwencję, może spełniać powierzchowny wymóg interakcji, oferując jednocześnie niewielki praktyczny nadzór. Osoba podejmująca decyzję potrzebuje wystarczającego kontekstu, aby ocenić rzeczywistą operację.

Ta presja dotyczy także zespołów platformowych utrzymujących współdzielone ustawienia domyślne. Potrzebują one spójnego słownictwa dla dozwolonych operacji, obowiązkowej kontroli i niedostępnych recenzentów. W przeciwnym razie poszczególne projekty rozwijają niezgodne założenia.

Precyzja ma tu argument produktywnościowy. Jasne granice skracają czas poświęcany na odtwarzanie, czy niepowodzenie było przypadkowe, oczekiwane czy możliwe do naprawienia. Sprawiają też, że rozmowy z pomocą techniczną są mniej zależne od domysłów.

Dla nabywców korporacyjnych jakość rozszerzenia obejmuje zatem to, jak dobrze komponent wyjaśnia swój zakres uprawnień. Sam zakres funkcji niewiele mówi o tym, czy zespół może przewidywalnie obsługiwać ten komponent.

Szersze znaczenie wydania polega na tej zmianie kryteriów oceny. Rozszerzenie powinno być oceniane na podstawie jego zachowania decyzyjnego, w tym sytuacji, w których otaczający przepływ pracy nie może zapewnić oczekiwanego zatwierdzenia.

Tryb Auto Przenosi Dyskusję Ku Kontekstowi Środowiska

Tryb auto to tryb uprawnień Claude Code służący do oceniania działań przy mniejszej liczbie rutynowych przerw ze strony człowieka. Klasyfikator, czyli system oceniający proponowane działania, uczestniczy w decydowaniu o tym, co zostanie wykonane.

Anthropic wprowadził tryb auto 24 marca 2026 roku. Aktualizacja z 10 lipca mówi, że stał się on ogólnie dostępny dla wszystkich użytkowników. Październikowe wydanie dotyczy więc istniejącej funkcji, a nie jej początkowego uruchomienia.

Anthropic przyznaje, że automatyczna ocena może zezwalać na ryzykowne działania lub blokować nieszkodliwe. Firma twierdzi również, że brakujący kontekst środowiskowy i niejednoznaczne intencje mogą wpływać na te decyzje.

Wartość automatyzacji zależy częściowo od tego, jak dokładnie system rozumie środowisko otaczające zadanie.

Znaczenie polecenia zależy od czegoś więcej niż jego tekstu. Ta sama operacja może mieć inne konsekwencje w jednorazowym środowisku programistycznym i we współdzielonym systemie operacyjnym.

Czyni to wiedzę o środowisku kwestią praktyczną, a nie kosmetyczną preferencją konfiguracji. Asystent potrzebuje kontekstu dotyczącego tego, co ma znaczenie, podczas gdy administratorzy potrzebują pewności, że dostarczony kontekst pozostaje aktualny.

Opisana wcześniej szersza dostępność konfiguracji ma największe znaczenie dla organizacji, których zatwierdzona ścieżka dostępu różni się od bezpośredniego połączenia. Brama chmurowa, pośrednik kierujący żądania modeli, często jest częścią takiego układu.

Mimo to dostęp przez zatwierdzoną ścieżkę nie rozwiązuje każdego pytania operacyjnego. Zespoły muszą rozróżniać łączność, dostępność funkcji, egzekwowanie polityki i użyteczność wynikowej konfiguracji.

Przykładowym przypadkiem jest repozytorium zawierające zarówno kod aplikacji, jak i skrypty operacyjne. Żądanie programisty dotyczące zbadania usterki może uzasadniać odczyt obu. Nie ustanawia jednak automatycznie uprawnień do każdej operacji obsługiwanej przez te skrypty.

Wynikające z tego napięcie jest proste. Większa wiedza o projekcie może poprawić trafność, lecz dodatkowy kontekst tworzy również więcej materiału, którego dokładność i zakres uprawnień wymagają interpretacji.

Ostatnia sesja może opisywać tymczasowe obejście problemu. Dokument projektu może odnosić się do środowiska, które już nie istnieje. Te możliwości są powodami, by z czasem oceniać jakość konfiguracji.

W tym miejscu określenie „mniej przerw” potrzebuje znaczącego punktu odniesienia. Zespół powinien zwracać uwagę, czy możliwe do uniknięcia pytania zanikają, podczas gdy istotne decyzje pozostają widoczne.

Przepływ pracy, który pyta rzadziej, lecz kieruje więcej pracy do ręcznego odzyskiwania, nie musi koniecznie poprawiać produktywności. Przerwa jedynie przenosi się z etapu zatwierdzania na etap analizy.

Moment wydania wyjaśnia również, dlaczego zasługuje ono na operacyjną interpretację. Gdy tryb uprawnień jest szeroko dostępny, kolejne pytania dotyczą dopasowania, jasności i spójności w rzeczywistych konfiguracjach wdrożeniowych.

Notatki Anthropic nie określają, w jakim stopniu rozszerzona konfiguracja poprawia jakość decyzji. Nie ma tu podstaw do przypisania wzrostu dokładności ani oszacowania skrócenia czasu kontroli.

Dla nabywców pozostawia to konkretne pytanie oceniające. Czy konfiguracja pomaga asystentowi rozróżniać rutynową pracę programistyczną od operacji niosących konsekwencje wykraczające poza bezpośrednie zadanie?

Odpowiedź wymaga obserwacji w zamierzonym środowisku. Dostępność potwierdza, że można dotrzeć do funkcji; dowody operacyjne potwierdzają, czy pomaga ona zespołowi.

Copilot Pokazuje, Dlaczego Kontrole Wykonania Pozostają Odrębną Kwestą

Dokumentacja bezpieczeństwa agentów GitHub opisuje agenta chmurowego Copilot jako działającego w efemerycznym środowisku za firewallem. Efemeryczne oznacza tymczasowe; firewall ogranicza ruch sieciowy.

Ta sama dokumentacja opisuje Copilot CLI jako lokalne środowisko wiersza poleceń, którego monity o uprawnienia zależą od aktywnego trybu. Są to różne układy wykonawcze w ramach jednej rodziny produktów.

Porównanie jest użyteczne, ponieważ ujawnia powszechny błąd zakupowy. Nazwa produktu nie identyfikuje każdej granicy otaczającej każdą sesję.

Obsługa uprawnień i izolacja wykonania zasługują na odrębną ocenę, nawet gdy dostawca oferuje je w jednym pakiecie.

To porównanie architektoniczne, a nie ranking bezpieczeństwa. Przeanalizowana tutaj dokumentacja nie uzasadnia stwierdzenia, że którykolwiek dostawca jest uniwersalnie bezpieczniejszy we wszystkich wdrożeniach.

Zamiast tego presja konkurencyjna dotyczy tego, jak jasno dostawcy wyjaśniają relację między autonomią a kontrolą. Nabywcy potrzebują opisów na tyle precyzyjnych, by dało się je odnieść do ich rzeczywistej pracy.

W przypadku chmurowego przepływu pracy programistycznej tymczasowe środowisko może obsługiwać określony proces przeglądu. W lokalnym przepływie pracy otaczająca maszyna i dostępne zasoby tworzą inny kontekst operacyjny.

System zatwierdzeń należy oceniać w tym kontekście. Wiedza, że działanie zostało dozwolone, mówi niewiele bez informacji, gdzie zostało wykonane i jakie zasoby były dostępne.

Rozróżnienie staje się konkretne podczas hipotetycznej aktualizacji zależności. Przygotowanie poprawki, uruchomienie testów projektu i publikacja pakietu to powiązane działania, lecz ich konsekwencje są różne.

Przydatny przepływ pracy agenta zachowuje te różnice przez cały czas trwania zadania. Nie powinien wymagać od administratora założenia, że każdy krok odziedziczył te same uprawnienia tylko dlatego, że początkowe żądanie brzmiało rutynowo.

Tworzy to praktyczne ramy porównawcze dla liderów inżynieryjnych. Mogą oni analizować, jak produkty wyrażają uprawnienia, jakich środowisk wykonawczych używają i jakie dowody pozostają dostępne do przeglądu.

Pytania te utrzymują również oceny w związku z rzeczywistymi zakresami odpowiedzialności. Deweloper może odpowiadać za poprawkę, podczas gdy inny zespół zarządza poświadczeniami wdrożeniowymi lub polityką sieciową.

Gdy produkt przekracza te granice odpowiedzialności, przekazanie musi pozostać zrozumiałe. W przeciwnym razie pozorna wygoda może sprawić, że organizacja nie będzie wiedziała, kto przyjął konsekwencje.

Dla dostawców stanowi to również wyzwanie dokumentacyjne. Marketing często opisuje ciągłe doświadczenie, podczas gdy odpowiedzialność operacyjna pozostaje podzielona między wiele systemów i właścicieli.

Najlepsze wyjaśnienia produktów uwidaczniają te podziały, nie zmuszając użytkowników do ich odtwarzania metodą inżynierii wstecznej. Jest to szczególnie istotne, gdy organizacje wspierają zarówno rozwój lokalny, jak i chmurowy.

W przypadku zmian uprawnień Claude Code takie porównanie utrzymuje analizę na właściwym gruncie. Bardziej jednoznaczna semantyka zatwierdzeń jest cenna w swoim zakresie, podczas gdy kontrole infrastruktury nadal wymagają niezależnej uwagi.

Pytanie konkurencyjne jest zatem szersze niż to, który asystent zadaje mniej pytań. Obejmuje ono również to, który produkt pomaga zespołowi wyjaśnić swoje decyzje po trudnym lub nieoczekiwanym zadaniu.

Porównanie konfiguracji nie może poświadczyć bezpieczeństwa wdrożenia

Wskazówki Anthropic dotyczące bezpieczeństwa wdrożeń obejmują ograniczenia sieciowe, obsługę poświadczeń, wybór narzędzi, zatwierdzenia, budżety i monitorowanie. Szeroki zakres tych wskazówek pokazuje, dlaczego konfiguracja zasługuje na osobny przegląd.

Porównanie konfiguracji może pomóc wskazać różnice między wdrożeniem a udokumentowaną rekomendacją. Daje to recenzentom bardziej konkretny punkt wyjścia niż nieformalne zapewnienie, że ustawienia wyglądają rozsądnie.

Raport porównawczy wspiera decyzję dotyczącą bezpieczeństwa; nie potwierdza bezpieczeństwa całej wdrożonej aplikacji.

Rozróżnienie wynika z samego zakresu konfiguracji. Ustawienia opisują wybrane mechanizmy kontroli, lecz zachowanie aplikacji zależy również od implementacji, integracji, praktyk operacyjnych i zasobów, do których może uzyskać dostęp.

Dokumentacja Anthropic dotycząca granic piaskownicy wyraźnie wskazuje to ograniczenie. Stwierdza, że zachowanie modelu nie jest mechanizmem kontroli bezpieczeństwa, oraz wyjaśnia, że niestandardowe narzędzia i infrastruktura hostowana samodzielnie zachowują odrębne zakresy odpowiedzialności.

Wskazówki odnoszą się również do prompt injection, czyli złośliwych instrukcji osadzonych w materiale czytanym przez agenta. Ostrzegają, że agent może ujawnić informacje poprzez odpowiedzi lub dane wyjściowe narzędzi.

Ten kontekst ogranicza wnioski, jakie czytelnicy powinni wyciągać z nowej funkcji porównawczej. Zgodność z rekomendacjami byłaby dowodem dotyczącym sprawdzonych ustawień, a nie potwierdzeniem obejmującym każdy możliwy przepływ pracy.

Hipotetyczne narzędzie wewnętrzne ilustruje tę lukę. Jego konfiguracja może wyglądać odpowiednio, podczas gdy samo narzędzie przyjmuje żądania wykraczające poza zamierzony cel biznesowy.

Kolejny przykład dotyczy odpowiedzialności operacyjnej. Raport może wskazać ustawienie wymagające przeglądu, lecz organizacja nadal potrzebuje osoby uprawnionej do podjęcia decyzji, czy rekomendacja jest odpowiednia.

Niektóre odstępstwa mogą wynikać z celowego wymogu. Inne mogą odzwierciedlać przeoczone ustawienie domyślne. Przydatny przegląd rozróżnia te przypadki i dokumentuje uzasadnienie, nie zakładając, że każda różnica ma to samo znaczenie.

Istnieje także ryzyko komunikacyjne. Zwięzły wynik może rozprzestrzenić się w firmie dalej niż towarzyszące mu zastrzeżenia. Nabywcy powinni unikać przekształcania porównania o ograniczonym zakresie w ogólne twierdzenie o certyfikacji.

Ta sama dyscyplina analityczna dotyczy rozróżnienia operacji tylko do odczytu. Operacja, która nie zmienia konfiguracji, może nadal generować ustalenia wymagające uważnej interpretacji i późniejszych decyzji.

Dla zespołów zakupowych istotne dowody obejmują zakres i ograniczenia porównania. Powinny one pytać, które ustawienia zostały sprawdzone, a które części wdrożenia pozostają poza tą kontrolą.

Dla deweloperów użytecznym wynikiem jest możliwe do zastosowania wyjaśnienie. Ustalenie powinno łączyć wybór konfiguracji z możliwością lub ekspozycją, na którą wpływa.

Dla zespołów bezpieczeństwa porównanie może służyć jako artefakt przeglądu. Jego wartość rośnie, gdy ustalenie, właściciel i ostateczna decyzja pozostają ze sobą powiązane.

W tym miejscu istotne staje się zarządzanie wiedzą techniczną. Przeszukiwalne zapisy techniczne pomagają zespołom zachować uzasadnienie wyborów konfiguracyjnych wraz z dokumentami, które je ukształtowały.

Nic z tego nie dowodzi, że nowe porównanie jest nieskuteczne. Ustanawia właściwy standard jego oceny: użyteczny zakres, jasne ograniczenia i ustalenia wspierające decyzje o jasno określonej odpowiedzialności.

Trzy sygnały pokażą, czy nadzór się poprawia

W nadchodzących miesiącach czytelnicy powinni obserwować dowody łączące te funkcje z mierzalnymi rezultatami. Najbardziej użyteczne sygnały dotyczą zachowania rozszerzeń, konfiguracji środowiska i przeglądu konfiguracji.

Lepszy nadzór powinien prowadzić do jaśniejszych decyzji i mniejszej liczby niewyjaśnionych rezultatów, a nie po prostu do większej liczby ustawień lub dłuższych transkrypcji.

Pierwszym sygnałem są publiczne, odtwarzalne dowody dotyczące obowiązkowego przeglądu przez człowieka. Przykłady rozszerzeń i ukierunkowane testy powinny umożliwiać odróżnienie pomyślnej obsługi zatwierdzenia od nierozwiązanego żądania.

Dowody powinny obejmować sytuacje bez nadzoru, gdy w otaczającym przepływie pracy nie ma dostępnego recenzenta. Przypadki te pokazują, czy integracja zachowuje deklarowany kontrakt pod presją operacyjną.

Spójne wyniki wzmocniłyby argument, że jednoznaczna semantyka decyzji poprawia przewidywalność. Sprzeczne zachowanie wskazałoby węższy problem implementacyjny wymagający zbadania.

Czytelnicy powinni również odróżniać zachowanie produktu od zachowania integracji. Awaria konkretnego rozszerzenia nie oznacza automatycznie uniwersalnej awarii całej bazowej platformy.

Drugim sygnałem jest udokumentowana jakość konfiguracji w ramach nowo wymienionych sposobów dostępu. Dostępność jest punktem wyjścia; użyteczne dowody opisywałyby, co zmieniło się w rzeczywistej pracy programistycznej.

Przekonująca ocena łączyłaby konfigurację z konkretnymi decyzjami. Wyjaśniałaby, które rutynowe pytania stały się zbędne, a które istotne operacje nadal otrzymywały odpowiednią kontrolę.

Raporty ograniczające się do stwierdzenia, że asystent wydawał się szybszy, oferują ograniczone wskazówki. Na to wrażenie mogą wpływać zestaw zadań, kontekst projektu i otaczająca polityka.

Jasne przykłady wzmocniłyby argument, że kontekst środowiskowy usprawnia praktyczną automatyzację. Powtarzające się niejasności dotyczące granic projektu osłabiłyby ten argument i wskazały na luki w dokumentacji lub konfiguracji.

Trzecim sygnałem jest użyteczność ustaleń dotyczących konfiguracji w czasie. Recenzenci powinni szukać przejrzystego zakresu, zrozumiałych wyjaśnień oraz wyraźnego rozróżnienia między rekomendacjami a wymuszanymi mechanizmami kontroli.

Znaczący raport pomaga organizacji zdecydować, co zmienić i dlaczego. Uspokajająca etykieta bez wystarczających informacji o zakresie wnosi mniej do tej decyzji.

Dowody na wykryte i celowo rozwiązane problemy wspierałyby operacyjną wartość funkcji porównawczej. Ustalenia wielokrotnie błędnie rozumiane ujawniłyby problem komunikacyjny, nawet gdyby samo porównanie działało poprawnie.

Sygnały te nie wymagają przewidywania, który asystent zdominuje rozwój oprogramowania. Dotyczą bardziej bezpośredniego pytania: czy w praktyce łatwiej będzie nadzorować delegowaną pracę.

Claude Code v2.1.304 daje zespołom konkretne zachowania do zbadania, nie twierdząc, że problem nadzoru został rozwiązany. Jego znaczenie będzie zależało od tego, jak konsekwentnie rozszerzenia, aplikacje i praktyki wdrożeniowe zachowują te rozróżnienia.

Podczas następnego przeglądu wybierz reprezentatywny przepływ pracy i prześledź jego istotne decyzje od żądania do rezultatu. Określ, kto miał uprawnienia, jakie informacje stanowiły podstawę zatwierdzenia i jakie dowody pozostały później. Porównaj te obserwacje z granicami, które Twoja organizacja zamierzała egzekwować. Zachowaj nierozwiązane pytania przy odpowiedniej dokumentacji projektu, aby inny recenzent mógł później zrozumieć tok rozumowania. To ćwiczenie zapewnia temu wydaniu praktyczny standard oceny bez polegania na liczbie funkcji. Pytanie dla zespołu inżynieryjnego jest konkretne: czy osoby odpowiedzialne potrafią wyjaśnić, dlaczego asystent kontynuował działanie, dlaczego się zatrzymał i które części tego wyjaśnienia faktycznie zweryfikowały?