Задача и мой вклад
У обычного AI-чата короткая память и мало связи с реальной работой. А помощник с доступом к инструментам может сделать слишком много: перепутать проекты, повторить действие после сбоя или принять свою догадку за разрешение.
Мой вклад. Я определяю роли помощника, правила взаимодействия, границы памяти и условия выполнения действий. Отвечаю за логику продукта и конструкцию системы: какие решения помощник принимает сам, где обязан спросить и как пользователь понимает происходящее.
Вместо одной бесконтрольной цепочки — координатор и специализированные роли. История привязана к владельцу и диалогу. Факты попадают в общую память проекта только после подтверждения. Рискованные действия проходят отдельную очередь согласований.
Что получилось
В исходниках реализованы общий разговор для браузера и iPhone, голосовой ввод и ответы, история с настоящими авторами сообщений и подтверждения внутри чата. Это результат по возможностям продукта; экономия времени и число пользователей здесь не заявляются без измерений.
Инженерные решения
Не повторять неизвестное
Если исполнитель потерял ответ, это не означает, что действие не произошло. Резервный провайдер подключается только при допустимом сбое до выполнения.
Память с происхождением
Факт хранит ссылки на сообщения. Проверка владельца, версии и запись выполняются в одной транзакции — устаревший ответ модели не перезаписывает более свежую память.
Делегировать по делу
Координатор привлекает нужные роли. Ограничения вызовов и проверка циклов не дают переписке агентов стать бесконечной.
Архитектура
| Слой | Технологии и назначение |
|---|---|
| Интерфейсы | Telegram, Preact, SwiftUI; браузерный чат |
| Backend / AI | Bun, TypeScript, координатор ролей, Claude Agent SDK |
| Данные | SQLite WAL; диалоги, задания, согласования, память проектов |
| Инфраструктура | systemd, GitHub Actions, отдельный мост выполнения |
Компромиссы и выводы
SQLite упрощает эксплуатацию и позволяет атомарно обновлять память, но требует внимания к длительным операциям в одном процессе. Голос построен как запись → распознавание → ответ → синтез: это проще контролировать, но не одновременный разговор в обе стороны.
Что показала практика
В истории панели зафиксирована ошибка: счётчик считал «не на паузе» как «онлайн» и мог показывать 12/12 над красными индикаторами. Исправление связало счётчик и индикаторы с одной проверкой health. Вывод: состояние процесса и готовность выполнить работу — разные вещи.
Что бы я улучшил сейчас
Сейчас я бы начал с единого набора проверяемых сценариев для Telegram, браузера и iPhone, а затем измерял задержку ответа и время до согласованного действия. Это следующий шаг, а не уже полученные показатели.
Эксплуатация и данные
Сервис и панель разворачиваются отдельно от подписанной iPhone-сборки. Очереди, журнал действий и health-состояния помогают понять, что выполнено, что ожидает решения и что требует вмешательства. Секреты и рабочие базы не входят в публичный репозиторий.
Данные и миграции
Диалог принадлежит владельцу; связь с проектом хранится отдельно. Память диалога имеет ревизию, предложение на публикацию фиксирует её снимок, а подтверждённый факт сохраняет происхождение. Новые таблицы добавляются без изменения существующих диалогов.
| Слой | Связь / правило |
|---|---|
| Диалоги | owner → conversation → messages |
| Память | conversation → revision + sourceMessageIds |
| Проекты | project → approved knowledge |
| Согласования | proposal → решение владельца → действие |
Ограничения
Для работы нужны учётные записи провайдеров и настройка владельца. Публичного доступа к рабочим чатам нет. Виртуальный офис 2D/3D и GitHub MCP находятся в отдельной ветке разработки; банковское исполнение не заявляется как готовая возможность.
Проверяемые источники
Проверено 24.09.2026: 15 проверок памяти и правил fallback; сборка панели. Это целевая проверка описанных решений, не аудит всего приложения.
Утверждения выше связаны с публичным кодом и документацией. Ссылки закреплены за проверенной версией; статус CI по ссылке может меняться.