Трекер задач на своём сервере для веб-студии: запуск, перенос истории, русификация

Решение и подход

Инфраструктура. Стек Plane запускается официальным релизным docker-compose (APP_RELEASE=v1.3.0, не stable) со встроенными Postgres 15.7, Valkey (Redis), RabbitMQ и MinIO. Поверх — собственный docker-compose.override.yml с healthcheck'ами, security_opt: no-new-privileges и тюнингом Postgres под 4 GB (max_connections=50, shared_buffers=512MB и др.); вариант с mem_limit/cpus сохранён отдельным .disabled-файлом для включения одной командой. Внешний Caddy v2 в отдельном compose-проекте проксирует на внутренний plane-proxy через external docker network. Поскольку домен был зарегистрирован за сутки и A-запись ещё не пропагирована, TLS поднимался поэтапно: старт на tls internal (self-signed) → после пропагации DNS переключение на Let's Encrypt без даунтайма (caddy reload).

Миграция. Дизайн целевой структуры зафиксирован в mapping-design.md до импорта. Сообщения Telegram классифицируются LLM по 12 категориям (requirements / task_actionable / status_update / estimate_request / noise и т.д.); связные ТЗ агрегируются в issue «Brief/ТЗ», reply-цепочки превращаются в дерево комментариев, ссылки на Figma/Drive — в issue links. Состояние пишется в import-state.jsonl (по строке на сущность с plane_id и привязкой к tg_message_id), что делает повторный --apply идемпотентным и даёт rollback. Ключевое нетривиальное решение — приватность оценок: в Plane CE нет per-issue ACL, поэтому оценки выносятся в отдельные private-проекты (Estimates — <Name>, members = [сотрудник, директор]); видимость network=0 выставляется прямым UPDATE в Postgres через SSH→docker exec psql (whitelisted SQL), а «зеркальное правило» вырезает любые суммы/часы из публичных проектов.

Локализация. Разобрана архитектура i18n Plane (кастомный mobx-store + intl-messageformat, локали как TS-модули export default {.} as const, EN-core.ts как fallback). На основе coverage-аудита и бенчмарка российских аналогов составлен глоссарий (Work item → «Задача», Intake → «Заявки», Due date → «Срок выполнения» и т.д.), затем — правки ru/*.ts, патчи hardcoded-строк в apps/web/, передача ru-локали в date-fns и авто-патчер EN→RU-ключей. Так как переводы «запекаются» в Next.js-билд, подготовлен runbook сборки кастомного frontend-образа локально (на VDS сборка падала бы по OOM) и переноса через docker save | ssh | docker load.

Стек и обоснование

• Plane CE v1.3.0 — open-source, AGPL, self-hosted: независимость от облачных PM-сервисов и полный контроль данных команды.
• Docker / docker-compose — официальный способ поставки Plane; воспроизводимость через override-файлы.
• Caddy v2 — автоматический ACME/Let's Encrypt, HTTP/3, лаконичный Caddyfile; вынесен наружу, чтобы не трогать внутренний proxy Plane.
• PostgreSQL / Valkey / RabbitMQ / MinIO — встроенные зависимости Plane; Postgres дополнительно затюнен под 4 GB и используется напрямую (psql) для операции, недоступной через API.
• Python + REST API + Telegram API — пайплайн миграции; tenacity для backoff на 429/5xx, idempotent state в JSONL.
• LLM-API (единый доступ к нескольким моделям) — компонент пайплайна миграции для классификации сообщений; кэширование удешевляет проход по 500+ сообщениям, смена модели — через env.
• Next.js / TypeScript — слой локализации Plane; правки требуют пересборки frontend-образа.
• UFW / fail2ban / unattended-upgrades / swap — базовая защита и устойчивость одиночного VDS.

Инженерные вызовы

• DNS не пропагирован на старте (домен в зоне ~24 ч) — Let's Encrypt HTTP-01 сразу не прошёл бы; решение — двухфазный TLS (self-signed → LE) с переключением одним reload.
• Жёсткие 4 GB RAM — тюнинг Postgres, лимиты как «потолок», сборка frontend только локально (на VDS — OOM), перенос образа через docker save/load.
• Отсутствие per-issue ACL в Plane CE — приватность финансовых оценок реализована через private-проекты + прямой UPDATE projects SET network=0 в Postgres (whitelisted SQL по SSH), плюс автоматическая вырезка сумм из публичных проектов.
• Идемпотентность и откат миграции — JSONL state-machine с привязкой каждой созданной сущности к исходному Telegram-сообщению; повторный прогон пропускает уже залитое.
• Шумные неструктурированные данные Telegram — LLM-классификация по 12 категориям с отбраковкой noise (стикеры, «ок», «+») и ручной доревизией спорных кейсов.
• Безопасность доступа — план изменения sshd_config с обязательной параллельной safety-сессией и rescue-консолью провайдера на случай локаута.