Блог Laraue — .NET, Nuxt, Telegram-боты и работа с ИИ

Часть 26 цикла о разработке Telegram-таск-трекера небольшой командой. Как в Boards появился ИИ, который превращает поток мыслей из чата в аккуратную задачу: DeepSeek в продакшене, Ollama для локальной разработки, свой OpenAI-совместимый клиент на HttpClient и команда /aisave в Telegram.

Часть 25 цикла о разработке Telegram-таск-трекера небольшой командой. Как бот Boards научился работать в групповых чатах: привязка чата к доске командой /link, два режима сохранения сообщений, проверка администратора, privacy mode и переход группы в супергруппу.

Часть 24 цикла о разработке Telegram-таск-трекера небольшой командой. Как токен веб-приложения переехал из localStorage в HttpOnly-cookie: как ASP.NET Core читает JWT из cookie, что для этого понадобилось фронтенду на Nuxt, как настроить CORS и как мы упростили локальный запуск проекта.

Часть 23 цикла о разработке Telegram-таск-трекера небольшой командой. Почему интерфейс Boards пришлось переписать, как устроена новая архитектура фронтенда, в которой каждая страница явно объявляет свои зависимости, как это помогает тестам на Vitest и зачем в репозитории файл с правилами для ИИ-агентов.

Часть 22 цикла о разработке Telegram-таск-трекера небольшой командой. Как устроены комментарии к задачам в Boards: кто может их читать, писать и редактировать, почему они загружаются отдельным запросом в фоне и как работает пагинация без запроса COUNT.

Часть 21 цикла о разработке Telegram-таск-трекера небольшой командой. Как мы научили веб-приложение загружать картинки в задачи и хранить их в Telegram через бота и свели файлы из бота и из веба к одной модели вложений.

Часть 20 цикла о разработке Telegram-таск-трекера небольшой командой. Как в Boards появилась история изменений задач, почему мы пишем её явно в сервисах в той же транзакции, что и сами изменения, и почему не подошли интерсепторы EF Core, темпоральные таблицы и event sourcing.

Часть 19 цикла о разработке Telegram-таск-трекера небольшой командой. Как мы добавили к задачам атрибуты (кастомные поля), почему выбрали модель EAV с отдельной таблицей значений для каждого типа, а не колонку JSONB, и как работает фильтрация задач по значениям атрибутов.

Часть 18 цикла о разработке Telegram-таск-трекера небольшой командой. Как у issues появились последовательные номера вида BRD-42, почему для них подошёл счётчик на INSERT ... ON CONFLICT DO UPDATE, а не sequence в PostgreSQL, как устроены ключи спейсов и URL организаций.

Часть 17 цикла о разработке Telegram-таск-трекера небольшой командой. Почему в Boards нет ролей, как система прав прошла через четыре версии в поисках баланса между гибкостью и простотой и почему права в итоге выдаются только на уровне организации и спейса.

Часть 16 цикла о разработке Telegram-таск-трекера небольшой командой. Как мы добавили в Boards организации: модель данных с общей базой, личную организацию для каждого пользователя, вступление по коду приглашения и отдельный JWT, который выдаётся при входе в организацию.

Часть 15 цикла о разработке Telegram-таск-трекера небольшой командой. Почему мы написали первые интеграционные тесты, когда приложение уже работало в продакшене, как устроен тестовый хост на WebApplicationFactory с настоящей базой и собственный прокси, который превращает вызов метода контроллера в HTTP-запрос.

Часть 14 цикла о разработке Telegram-таск-трекера небольшой командой. Как спейсы группируют доски по проектам, почему спейс хранится у доски, а не у issue, и SQL-миграция, которая дала каждому пользователю спейс по умолчанию.

Почему мы удалили собственный бэкенд, отдающий markdown как API, и перенесли блог в приложение на Nuxt — вечная синхронизация фронтенда с бэкендом, возможности, которых не хватало, и что упростилось после переезда.

Часть 27 цикла о разработке Telegram-таск-трекера небольшой командой. Мы сделали MCP-сервер для Laraue Boards, чтобы разобраться, как работает MCP, а потом начали пользоваться им с Claude Code каждый день. Как за два часа появилась первая версия, что было в ней не так и какой ежедневный цикл он дал.

Современный подход к разработке все больше сводится к тезису - код должен писать ИИ, а разработчик лишь направляет его в нужную сторону и проверяет результаты. А то, что отревьюить сгенерированный код так, чтобы ему довериться, часто дольше, чем написать его самостоятельно, старательно опускается.