Що ми встановили. Хто продовжує. Що далі.

Працює у production і є board, на якому ми ведемо нашу компанію. Цифри: 566 commit-ів, останній — 4 вересня 2026; 81 міграція, що створює 90 таблиць; 171 політика доступу на рівні рядка; 563 автоматизовані test-cases у 38 файлах; 21 запланована routine на server плюс 9 loops у процесі; 14 інструментів MCP; 35 endpoint-ів на збирачі. Чим це не є: service з autoservice. Немає кнопки, через яку зовнішня команда може самостійно його запустити — його встановлюють.

Ні, і обмеження в базі даних, а не в інтерфейсі. Функція типу guard не дає agent-у закрити task, а будь-який запис, що закриває його, має вказати actor; якщо actor не можна встановити, запит відхиляється. Варто також сказати, чому правило виглядає саме так: перша версія визначала actor через функцію, яка повертала порожнє значення для автоматичного service, тож вона не застосовувалася ніде. Власний audit це виявив, а міграція, яка це виправила, у коментарі пояснює точно, що не працювало.

Насправді, з кодом і з запланованою routine: Telegram (власний bot, постійне прослуховування, транскрипція voice-повідомлень), чотири mail-скриньки — три Gmail і одна Microsoft 365 — лише для читання, Google Calendar, телефонні дзвінки через SIP-trunk, Obsidian, LinkedIn, а також sessions роботи й git-activity, зчитані з комп’ютера людини. Models проходять через власний gateway, сумісний з OpenAI; engine виконання agent-ів працює на OpenRouter. Що НЕ підключено, хоча наша сторінка integrations це показує: Slack, GitHub, Jira, Notion, Figma, Zapier, Dropbox, Google Drive, Microsoft Teams, GitLab, Outlook. Ми шукали в code і не існує жодного рядка для жодного з них. Та сторінка — це marketing grid, і її треба виправити.

Ні, попри назву екрана в application. Цей екран насправді є pairing пристрою через QR code, у стилі, до якого люди звикли з WhatsApp Web — звідси й назва. Жодного call до будь-якого WhatsApp API немає. Ба більше: цей flow не використовується, а його tables порожні, що констатує навіть migration, яка переглянула їхні permissions.

Корисна частина не в тому, що в нас є access policies, а в тому, що ми знайшли їхні прогалини й виправили їх одну за одною, кожна migration пояснює, що не працювало. Власний audit у серпні виявив, що всі три agent-guards були неактивні. Інша guard виявилася fail-open — перевірку було повністю пропущено, а не відхилено — і її перевели в fail-closed. Третя проблема була тонка й загальна: у Postgres нова function за замовчуванням виконується для всіх, тож явне надання прав нічого не обмежувало; на production перевірили, що anonymous key потрапляв у body function-и, після чого скасували право за замовчуванням. На рівні repository guard відхиляє direct push-і в main branch і блокує files із secrets, бо приватний repository на personal account не може мати branch protection від GitHub.

Три речі, про які ми воліємо сказати. Згенеровані типи для бази даних застаріли з січня і містять таблиці з абсолютно не пов’язаного проєкту, через що довелося зробити 101 примусове перетворення типу в 26 файлах — працює, але втрачає перевірку на етапі compilation саме там, де вона була б корисною. Перевірка стилю повідомляє про 161 успадковану помилку і не блокує delivery. І 36 tests пропускаються в CI, бо їм потрібен model key, якого там немає. Жоден із них не зупиняє product; усі три — реальний борг.

Через rsync, не контейнер: інтерфейс потрапляє до статичного каталогу, який обслуговує nginx, збирач і сервер MCP працюють як служби systemd. Безперервна інтеграція запускає тести й збирає; доставлення починається лише якщо вони пройшли на основній гілці, через власний виконавець, який має право запускати рівно два скрипти і нічого більше. Кожна зовнішня дія в pipeline зафіксована на її повному хеші, а не на мітці, після компрометації популярної дії в березні 2026 року. Перевірка стану читає, на який пакет посилається сторінка, і виконує відкат, якщо це не найсвіжіший — правило, написане після реального інциденту 3 вересня 2026 року. Базові міграції бази даних залишаються ручними, навмисно.