Claude Code v2.1.305 dodaje kompatybilność z Linuksem kosztem kompromisu w sandboxie

Anthropic wydał Claude Code v2.1.305 z opcją kompatybilności dla Linuksa, opatrzoną wyraźnym ostrzeżeniem: polecenia mogą ominąć ochronę plików zapewnianą przez sandbox. Wydanie rozwiązuje również problemy z dostawcami i ponownymi próbami bez nadzoru. Łącznie zmiany te wysuwają praktyczne pytania dotyczące wdrożenia przed głośne możliwości modeli.

Główne napięcie dotyczy użytecznej automatyzacji i egzekwowalnych granic. Deweloperzy chcą asystenta, który potrafi wykonywać realistyczne zadania bez zatrzymywania się z powodu problemów środowiskowych. Zespoły bezpieczeństwa muszą wiedzieć, które ograniczenia pozostają skuteczne po zmianie ustawień kompatybilności. Samo pomyślne wykonanie polecenia nie odpowiada na to pytanie.

GitHub Copilot stanowi użyteczne porównanie, ponieważ jego dokumentacja również opisuje kontrolę wykonywania z konkretnymi ograniczeniami. To porównanie operacyjne, a nie twierdzenie, że produkty mają wspólną architekturę. Dla organizacji oceniających agentów programistycznych istotne pytanie staje się coraz bardziej konkretne: do czego oprogramowanie ma dostęp, gdy nikt nie patrzy?

Co zmienia Claude Code v2.1.305

Najistotniejszym dodatkiem jest ustawienie kompatybilności z jasno określonym kosztem bezpieczeństwa.

Według informacji o wydaniu, sandbox.allowNestedUserNamespaces pozwala poleceniom Linuksa tworzyć przestrzenie nazw użytkowników, które dają procesom odrębne widoki tożsamości użytkowników i uprawnień. Anthropic wskazuje jako przykłady Chromium, silnik przeglądarki, oraz rootless Podman, narzędzie kontenerowe działające bez konta administratora. Ostrzega, że pozwala to ominąć ochronę plików sandboxa.

Wydanie dodaje również CLAUDE_CODE_RETRY_WATCHDOG_USAGE_LIMIT_RECHECK_MS dla trybu ponawiania bez nadzoru, umożliwiając wcześniejsze wykrycie zniesienia limitu użycia. Naprawia regresję w v2.1.304 dotyczącą Vertex, Bedrock i innych dostawców, gdy endpointy lub bramki odrzucają wyszukiwanie narzędzi. Claude Code ponawia teraz próbę bez tej możliwości.

Inne poprawki obejmują dopasowywanie nazw modeli dla /effort i /autocompact, zachowanie worktree oraz bardziej zrozumiałe błędy pełnego dysku. Worktree to oddzielny katalog roboczy powiązany z repozytorium Git. Zmiany te dotyczą niezawodności konfiguracji i wykonywania, a nie nowo ogłoszonego modelu.

To rozróżnienie ma znaczenie przy ocenie tego, co oznacza ta aktualizacja. Nic w tych szczegółach nie dowodzi lepszego rozumowania, wyższej trafności kodowania ani poprawy bezpieczeństwa w każdym środowisku. Bezpośrednia historia dotyczy dopasowania agenta do infrastruktury, która ma własne ograniczenia i warunki awarii.

Dodatki wymagają też odmiennego traktowania podczas aktualizacji. Naprawa przywracająca żądania przez istniejącą bramkę usuwa nieprawidłowe działanie. Ustawienie zmieniające możliwości poleceń wymaga decyzji politycznej. Traktowanie obu jako rutynowych udogodnień zacierałoby różnicę między ich konsekwencjami.

Dla zespołu deweloperskiego tworzy to nierównomierną ocenę wydania. Niektóre zmiany wymagają sprawdzenia, czy istniejący przepływ pracy znów działa. Inne wymagają sprawdzenia, czy przepływ pracy nadal działa w akceptowalnych granicach. To odrębne kryteria akceptacji, nawet gdy pojawiają się w tym samym pakiecie.

Opublikowane notatki przedstawiają opis zmian według Anthropic. Nie dostarczają niezależnych pomiarów niezawodności ani pełnej oceny bezpieczeństwa. Ta analiza nie testowała kompilacji, nie odtworzyła obejścia ani nie mierzyła czasów odzyskiwania.

Najbardziej klarowna interpretacja jest więc ograniczona, lecz użyteczna. Claude Code v2.1.305 zmniejsza tarcia związane z rzeczywistymi środowiskami wykonywania, jednocześnie ujawniając decyzję, której nie da się sprowadzić do stwierdzenia „polecenie teraz działa”. Kompatybilność ma wartość, ale znaczenie mają warunki, z którymi ta wartość jest związana.

Zespoły platformowe dziedziczą decyzję o kompatybilności

Największy ciężar decyzyjny spoczywa na osobach odpowiedzialnych za współdzielone środowiska programistyczne.

Pojedynczy deweloper może ocenić lokalny eksperyment pod kątem własnych potrzeb. Zespół platformowy musi ocenić, czy ta sama konfiguracja powinna obowiązywać w repozytoriach, na maszynach i w zadaniach bez nadzoru. Dopuszczalna odpowiedź zależy od tego, co zawierają te środowiska i jakie uprawnienia mają ich procesy.

Rozważmy hipotetyczny zespół proszący agenta o zbadanie awarii testu przeglądarkowego. Badanie może wymagać uruchomienia przeglądarki, analizy wyników i zmiany kodu aplikacji. Jeśli ograniczenia wykonywania blokują przeglądarkę, zespół staje przed natychmiastowym problemem z realizacją zadania. Wyjątek kompatybilności może wydawać się atrakcyjny, ponieważ usuwa widoczną blokadę.

Mniej widoczne pytanie dotyczy wszystkiego innego, co jest dostępne w tym środowisku. Uruchomienie testu na jednorazowej maszynie ma inny profil ryzyka niż uruchomienie go obok wrażliwych plików. Ten sam opis zadania może zatem uzasadniać różne konfiguracje, zależnie od miejsca wykonywania.

Dlatego pomyślna demonstracja ma ograniczoną wartość dla polityki. Dowodzi, że określona ścieżka została ukończona w konkretnych warunkach. Nie ustala jednak, czy niepowiązane pliki pozostały chronione ani czy dane uwierzytelniające nie zostały niepotrzebnie ujawnione. Te pytania wymagają dowodów wykraczających poza zaliczony test.

Wcześniejsza architektura sandboxingu Anthropic przedstawiała ograniczenia systemu operacyjnego jako sposób na zmniejszenie liczby powtarzanych zgód przy jednoczesnym ograniczaniu wykonywania. Jej uzasadnienie łączy autonomię zarówno z granicami systemu plików, jak i sieci. Ta historia wyjaśnia, dlaczego zmiany wpływające na te granice zasługują na uwagę.

Presja organizacyjna działa w przeciwnych kierunkach. Deweloperzy odbierają zablokowane polecenia jako stratę czasu. Recenzenci bezpieczeństwa postrzegają osłabione ograniczenia jako zwiększoną ekspozycję. Właściciele platform muszą stworzyć środowisko, które umożliwia zamierzony przepływ pracy, nie pozostawiając żadnej ze stron w przekonaniu, że druga zajęła się konsekwencjami.

Jawny wyjątek może być łatwiejszy do zarządzania niż nieudokumentowane obejście. Daje recenzentom coś konkretnego do omówienia i zapisania. Jego widoczność nie przesądza jednak o jego zasadności. Decyzja nadal zależy od zadania, dostępnych zasobów i otaczających zabezpieczeń.

Natychmiastowa reakcja powinna być więc specyficzna dla obciążenia roboczego. Zespoły oceniające nową opcję potrzebują uzasadnienia powiązanego z rzeczywistym wymaganiem wykonawczym. Ogólna preferencja dla mniejszej liczby przerw nie jest wystarczającym dowodem, że każde środowisko programistyczne powinno otrzymać tę samą zmianę.

Zmienia to także wygląd użytecznej dokumentacji wewnętrznej. Zapisanie wyłącznie wartości ustawienia pozbawia przyszłych opiekunów pierwotnego uzasadnienia. Zapisanie zablokowanego obciążenia roboczego, założeń środowiskowych, właściciela i warunków przeglądu czyni decyzję zrozumiałą, gdy zmieniają się zależności lub infrastruktura.

Presja ma charakter operacyjny, a nie teoretyczny. Ktoś musi być właścicielem konfiguracji po zakończeniu początkowej sesji rozwiązywania problemów. W przeciwnym razie wąsko uzasadniony wyjątek może utrzymywać się długo po zniknięciu obciążenia roboczego, które go uzasadniało.

Etykieta sandboxa nie opisuje całej granicy

Decyzje dotyczące bezpieczeństwa zależą od rzeczywistego zachowania, a nie od obecności słowa „sandbox”.

Sandbox to granica wykonywania, która ogranicza dostęp programu do otaczających zasobów. Termin ten nie określa każdego chronionego zasobu ani procesu. Jego znaczenie zależy od implementacji, konfiguracji i ścieżek, przez które rzeczywiście przebiega praca.

Aktualna dokumentacja sandboxa powłoki Claude Code rozróżnia wykonywanie w powłoce od wbudowanych narzędzi plikowych, hooków i zewnętrznych serwerów narzędzi. Oddziela także ograniczenia plikowe od ograniczeń sieciowych. Te rozróżnienia zapobiegają zastąpieniu rozumienia poszczególnych mechanizmów szeroką etykietą produktu.

Nową opcję należy oceniać w tych węższych ramach. Ostrzeżenie Anthropic dotyczy ochrony plików. Nie dowodzi, że znikają wszelkie ograniczenia sieciowe, że każde wdrożenie staje się podatne ani że opcja jest włączona powszechnie. Rozciąganie twierdzenia tak daleko wykraczałoby poza dostępne dowody.

Użytecznym sposobem oceny każdej zmiany granicy jest pytanie, co pozostaje po niej egzekwowalne. To pytanie jest bardziej informacyjne niż pytanie, czy funkcja jest ogólnie „bezpieczna”. Wymusza ono skierowanie dyskusji na konkretne zasoby, procesy i warunki, a nie na niejednoznaczną ocenę ogólną.

Na przykład wyobraźmy sobie organizację korzystającą z zewnętrznego, jednorazowego środowiska wokół swojego agenta programistycznego. To środowisko może zapewniać ograniczenia niezależne od własnych ustawień agenta. To, czy ograniczenia te są wystarczające, wymaga odrębnej oceny. Ich istnienia nie należy ani zakładać, ani odrzucać dlatego, że zmienia się kontrola wewnętrzna.

Odwrotne założenie jest równie słabe. Nazwanie czegoś kontenerem nie dowodzi, że nie ma w nim wrażliwych plików ani że dane uwierzytelniające nie mają szerokich uprawnień. Recenzenci muszą zbadać zasoby rzeczywiście udostępnione procesowi. Same nazwy architektury nie odpowiedzą na te pytania.

To jest główny kompromis tego wydania. Rozszerzenie kompatybilności wykonywania może pomóc agentowi realizować uzasadnione zadania. Jeśli rozszerzenie osłabia granicę, na której polegano, środowisko wymaga nowej oceny. Korzyść i koszt należą do tej samej decyzji.

Istotne dowody powinny obejmować zarówno zachowanie pozytywne, jak i negatywne. Pozytywny wynik pokazuje, że zamierzone obciążenie robocze działa. Negatywny wynik pokazuje, że działanie poza zamierzonym zakresem nadal jest blokowane. Bez tego drugiego sprawdzenie kompatybilności niewiele mówi o izolacji.

Takie kontrole powinny wykorzystywać nieszkodliwe zasoby testowe zamiast wrażliwych danych. Celem jest zweryfikowanie ograniczenia, a nie wywołanie incydentu podczas jego badania. Kontrolowany test może ujawnić, czy deklarowana granica odpowiada oczekiwaniom zespołu.

Istnieje również problem komunikacyjny. „Sandbox włączony” to wygodny komunikat o stanie, lecz kompresuje wiele szczegółów do binarnego opisu. Zespoły podejmujące decyzje wdrożeniowe potrzebują wersji rozszerzonej: które procesy są objęte ochroną, które zasoby są ograniczone i jakie wyjątki obowiązują.

Nie czyni to sandboxingu nieprzydatnym. Czyni precyzję niezbędną. Jasno opisany, celowo ograniczony mechanizm kontroli jest bardziej użyteczny niż szerokie zapewnienie, które czytelnicy interpretują na różne sposoby.

Odzyskiwanie po stronie dostawcy uwidacznia odrębny problem niezawodności

Agent musi pasować do otaczającego kontraktu usługowego, zanim jego zdolności programistyczne staną się istotne.

Naprawa dostawców w tym wydaniu dotyczy innej granicy: interfejsu między klientem a usługą odbierającą jego żądania. Bramka jest pośrednikiem, który kieruje tymi żądaniami lub nimi zarządza. Akceptowane przez nią możliwości mogą różnić się od oczekiwań klienta.

Dla użytkownika korporacyjnego odrzucone żądanie może przypominać awarię modelu, nawet jeśli sam model jest dostępny. Praktyczny skutek jest taki sam: praca zatrzymuje się, zanim rozpocznie się użyteczne rozumowanie. Zdiagnozowanie przyczyny wymaga oddzielenia dostępności usługi od kompatybilności żądania.

To rozróżnienie nadaje zachowaniu awaryjnemu znaczenie operacyjne. Opcjonalna funkcjonalność nie powinna automatycznie stawać się uniwersalnym wymogiem dostępności. Jednocześnie odzyskanie działania bez danej możliwości rodzi kolejne pytanie: czy operatorzy potrafią określić, jaka funkcjonalność pozostała dostępna podczas pomyślnego żądania?

Hipotetyczny agent może ukończyć zadanie po dostosowaniu żądania. Z perspektywy użytkownika odzyskanie działania jest pożądane. Z perspektywy operatora zapis powinien również wyjaśniać, co się zmieniło. W przeciwnym razie pozornie niespójne zachowanie może później być trudne do zbadania.

To szersza zasada niezawodności, a nie twierdzenie dotyczące nieudokumentowanego rejestrowania w tej wersji. Odzyskiwanie działania i obserwowalność muszą współdziałać. Obserwowalność oznacza posiadanie wystarczającej liczby zapisów, by zrozumieć zachowanie systemu. Udanej ponownej próbie łatwiej zaufać, gdy widoczne są jej przyczyny i konsekwencje.

Moment automatycznego odzyskiwania działania wprowadza powiązany problem. Zadanie może pozostać zablokowane po zmianie warunku, który je blokował. Dla zespołów polegających na wykonywaniu zadań w nocy użytecznym rezultatem jest ukończona praca, a nie tylko późniejsza świadomość, że jej wykonanie stało się możliwe.

Szybsze odzyskiwanie działania nie dowodzi jednak jego poprawności. Agent działający bez nadzoru musi również zachować stan zadania i unikać niepopartych założeń dotyczących wcześniejszych postępów. Operatorzy powinni oceniać wynik wznowionego uruchomienia, zamiast traktować samą aktywność jako dowód sukcesu.

Mechanizmy agent firewall controls GitHub ilustrują podejście innego produktu do zarządzanego wykonywania zadań. Dokumentacja opisuje ograniczony dostęp do internetu i wyraźnie wskazuje ograniczenia. Zapora sieciowa kontroluje ruch sieciowy; nie odpowiada na wszystkie pytania dotyczące plików, uprawnień ani zachowania aplikacji.

To porównanie wspiera ostrożny wniosek. Agenci programistyczni coraz częściej działają w systemach z kilkoma niezależnymi mechanizmami kontroli. Bramka żądań, ograniczenie systemu plików i zapora sieciowa rozwiązują różne problemy. Sukces na jednej granicy nie może dowodzić sukcesu na pozostałych.

To sprawia, że praktyczne oceny są bardziej wymagające niż demonstracja programowania. Kupujący muszą ocenić, czy agent potrafi ukończyć reprezentatywną pracę za pośrednictwem ich rzeczywistej infrastruktury. Potrzebują też dowodów, że ścieżki odzyskiwania działania zachowują ograniczenia i zapisy wymagane przez organizację.

Presja spoczywa na dostawcach, by wyjaśniali zachowanie, oraz na klientach, by testowali realistyczne warunki. Żadna ze stron nie korzysta na udanej demonstracji, która ukrywa założenia odrzucane przez infrastrukturę produkcyjną.

Czego wydanie nie dowodzi

Udokumentowana poprawka jest dowodem zamierzonej zmiany, a nie potwierdzeniem powszechnego sukcesu wdrożenia.

Dostępne materiały dotyczące wydania uzasadniają opisanie dodatków i napraw. Nie potwierdzają jednak ich skuteczności w każdej konfiguracji Linuxa, polityce bramki ani obciążeniu. To ograniczenie powinno pozostać widoczne, ponieważ środowiska te mogą różnić się w sposób istotny operacyjnie.

W cytowanych materiałach nie ma niezależnego benchmarku pokazującego, o ile poprawia się realizacja zadań bez nadzoru. Nie przedstawiono tu również odtworzonej oceny bezpieczeństwa definiującej pełne konsekwencje nowej opcji zgodności. Przypisanie zysku wydajności lub uniwersalnej oceny dotkliwości byłoby więc niepoparte dowodami.

Najbardziej sceptyczna interpretacja dotyczy jakości dowodów. Ustawienie może być jasno udokumentowane, a mimo to wymagać lokalnej weryfikacji. Dostawca może trafnie opisać naprawę, nie obejmując każdej konfiguracji klienta. Te możliwości uzasadniają testowanie; nie uzasadniają założenia, że wydanie zawodzi.

Zakres konfiguracji wprowadza kolejną komplikację. Dokumentacja settings precedence Claude Code rozróżnia źródła osobiste, projektowe i zarządzane. Wartość widoczna w jednym pliku nie musi wyjaśniać efektywnej konfiguracji. Osoby oceniające muszą rozumieć, co faktycznie ładuje się w ocenianej sesji.

Ma to znaczenie, gdy zespoły porównują wyniki. Programiści mogą uważać, że testowali identyczne konfiguracje, podczas gdy ich środowiska różnie rozwiązują ustawienia. Przed przypisaniem różnicy zachowaniu modelu osoby oceniające powinny ustalić, że warunki wykonania są wystarczająco zbliżone, by wspierać taki wniosek.

Ta sama ostrożność dotyczy twierdzeń o ustawieniach domyślnych. Samo istnienie nowego ustawienia nie dowodzi, że jest ono wszędzie włączone. Ostrzeżenie w wydaniu nie wykazuje również, że dana organizacja obecnie udostępnia wrażliwe pliki. Takie twierdzenia wymagają dowodów dotyczących wdrożenia tej organizacji.

Rzetelna ocena zachowuje pozytywną stronę argumentu. Ulepszenia zgodności mogą usuwać uzasadnione bariery dla użytecznej pracy. Czytelniejsze zachowanie odzyskiwania działania może ograniczać możliwe do uniknięcia przerwy. Żadna z tych korzyści nie wymaga twierdzenia, że każde wdrożenie powinno przyjąć każdą opcję ani że zniknęła wszelka niepewność.

Dla kupujących praktycznym ryzykiem jest sprowadzenie tych rozróżnień do jednej zgody. Decyzja o aktualizacji i decyzja o wyjątku zasługują na odrębne uzasadnienie. Pierwsza dotyczy zachowania nowej wersji. Druga dotyczy uprawnień, które organizacja zdecyduje się przyznać.

Dla programistów ryzykiem jest utrata kontekstu po pomyślnym rozwiązaniu problemu. Gdy zablokowane polecenie zaczyna działać, natychmiastowa motywacja do udokumentowania zmiany słabnie. Przyszli opiekunowie potrzebują jednak tego wyjaśnienia właśnie dlatego, że działająca konfiguracja nie sygnalizuje już problemu, który ją spowodował.

Zespoły mogą zachować te decyzje obok swojej technicznej bazy wiedzy. Użyteczny zapis obejmuje zaobserwowane zachowanie, założenia i nierozwiązane pytania. Powinien pomóc przyszłemu recenzentowi odtworzyć decyzję bez polegania na czyjejś pamięci.

Właściwy wniosek jest warunkowy. To wydanie oferuje zmiany warte oceny względem objętych nimi przepływów pracy. To, czy zmiany te uzasadniają szersze wdrożenie, zależy od dowodów z środowisk, w których agent będzie faktycznie działać.

Co obserwować po Claude Code v2.1.305

Kolejnymi użytecznymi sygnałami są odtwarzalne testy granic, dowody odzyskiwania działania i widoczność konfiguracji.

Pierwszym sygnałem jest udokumentowane testowanie opcji zgodności z Linuxem w realistycznych warunkach. Istotny wynik łączy pomyślne wykonanie z dowodami dotyczącymi pozostałych ograniczeń. Raporty powinny wskazywać środowisko i odróżniać zaobserwowane zachowanie od założeń dotyczących działania piaskownicy.

Jeżeli uzasadnione obciążenia będą działać, a niezależnie egzekwowana granica pozostanie zachowana, wzmocni to argument za kontrolowanym wdrożeniem. Jeżeli osoby oceniające nie potrafią ustalić, co nadal jest chronione, zaufanie powinno pozostać ograniczone. Sam pomyślny test w przeglądarce nie może rozstrzygnąć kwestii bezpieczeństwa.

Najbardziej użyteczne raporty rozróżnią również wewnętrzne ograniczenia agenta od otaczającej infrastruktury. To rozdzielenie pomogłoby czytelnikom zrozumieć, który komponent zapewnia każde zabezpieczenie. Bez niego pomyślny wynik może zostać błędnie uogólniony na wdrożenia pozbawione tych samych zewnętrznych mechanizmów kontroli.

Drugim sygnałem są dowody z dotkniętych przepływów pracy dostawców i zadań wykonywanych bez nadzoru. Zespoły powinny szukać ukończonych reprezentatywnych zadań przy swoich normalnych zasadach bramki. Powinny również sprawdzić, czy zapisy odzyskiwania działania wystarczająco jasno wyjaśniają przebieg zdarzeń, by operator mógł zbadać nieoczekiwane zachowanie.

Spójne ukończenie zadań wspierałoby twierdzenia Anthropic o niezawodności w tych testowanych warunkach. Powtarzające się awarie wymagające szerszych uprawnień lub niewyjaśnionych zmian konfiguracji osłabiłyby zaufanie do wyniku wdrożenia. Każdy z tych rezultatów byłby bardziej informacyjny niż ogólny raport, że aktualizacja wydaje się lepsza.

Trzecim sygnałem jest wyraźniejsza widoczność efektywnej konfiguracji. Przyszłe zmiany w dokumentacji lub interfejsie, które ujawniają wyjątki zmieniające granice, ułatwiłyby audyt tych decyzji. Jednoznaczne wyjaśnienia zakresu i konsekwencji zmniejszyłyby również ryzyko, że różne zespoły inaczej zinterpretują ten sam status.

Jeżeli ustawienia zgodności staną się łatwiejsze do zrozumienia i przeglądu, kompromis stanie się bardziej możliwy do zarządzania. Jeżeli wyjątki będą się kumulować bez jasnej odpowiedzialności, złożoność operacyjna wzrośnie. To kryterium obserwacji, a nie prognoza dotycząca kolejnego wydania Anthropic.

Te sygnały skupiają uwagę na dowodach, które zmieniają decyzję o wdrożeniu. Pozwalają uniknąć wykorzystywania niezwiązanych zapowiedzi dotyczących modeli jako wskaźnika niezawodności wykonania. Lepsze zdolności programistyczne same w sobie nie rozwiałyby niepewności dotyczącej dostępu do plików, działania bramki ani odzyskiwania działania bez nadzoru.

Dla zespołów rozważających Claude Code v2.1.305 punktem wyjścia powinno być obciążenie, które czyni aktualizację istotną. Należy określić, czy oczekiwana korzyść dotyczy naprawionej ścieżki żądań, wznowionej automatyzacji czy wyjątku wykonawczego. Następnie należy ocenić tę korzyść względem rzeczywistego środowiska, a nie ogólnej demonstracji produktu.

Wybierz reprezentatywne zadanie i zdefiniuj sukces przed oceną wydania. Zapisz oczekiwany wynik, dozwolone zasoby oraz zachowanie, które powinno pozostać zablokowane. Decyzję dotyczącą zgodności zachowaj oddzielnie od decyzji o aktualizacji i zachowaj wystarczające dowody, aby inny recenzent mógł zrozumieć obie. Gdy wyjątek jest konieczny, przypisz mu właściciela i uzasadnienie powiązane z obciążeniem. Gdy dowody pozostają niepełne, zachowaj tę niepewność zamiast przekształcać udane uruchomienie w szerokie zapewnienie. Potraktuj Claude Code v2.1.305 jako okazję do odpowiedzi na konkretne pytanie: czy ten agent może ukończyć zamierzoną pracę w granicach, które zespół potrafi wyjaśnić i zweryfikować?