TODO — Alatyr Infrastructure¶

Единый реестр активных задач. Закрытые задачи: TODO-archive.md. Исторические описания и прежние ID: TODO-legacy-2026-08.md. Личные задачи владельца (финансы, быт, семья): PERSONAL-TODO.md.

Правила¶

Проекты: MT — мультитенантный контур платформы (архитектурный якорь); INF — общая инфраструктура; CRM — alatyr-service; TAV — alatyr-taverna; DEF — DeFi-анализатор; VAULT — Vaultwarden; RAG — RAG-платформа.
Приоритеты: P0 — безопасность/аварийный риск; P1 — следующий обязательный контур; P2 — план; P3 — после основного; Later — отдалённый бэклог.
Оценки времени: формат Ч ч / К дн где Ч — чистые часы активной работы (соло + ИИ-ассистент), К — календарные дни при текущем темпе (~3–5 продуктивных часов в день). Оценки грубые (±40%), уточняются перед началом задачи.
Внутри проекта задачи расположены по приоритету, затем по рекомендуемому порядку выполнения. Номер ID стабилен и не обозначает приоритет.
Секреты не записывать в чат и git. Контрольные запросы к RAG/OpenWebUI и МоёДело не выполнять без отдельного указания владельца.
Ежедневный дайджест Alatyr KB ba645ae6 отключён 27.08.2026. Не создавать повторно без отдельного решения владельца.
Старые ID сохранены только в исторических документах. Соответствие старых и новых ID: todo-id-migration-2026-08-27.md.

Архитектурный принцип (обязателен для всех новых задач CRM/RAG/INF)¶

Multi-tenant by default. Любая новая таблица, API, RAG-коллекция и UI-контекст должны нести tenant_id (или наследовать его от родителя) уже сейчас. Даже если работает один тенант «ИП Головин Р.Ю.» — колонка есть, индексы есть, фильтры в запросах есть. Это позволяет: - добавить второго тенанта (внешняя компания как клиент SaaS) без миграции данных - предложить корпоративному заказчику собственный tenant с изолированным контуром без переписывания - изолировать RAG-знания объектов не только по объекту, но и по тенанту

Запрещено новыми PR: запросы, которые фильтруют только по owner_company_id без tenant_id; RAG-коллекции без tenant_id в metadata; API-endpoints без tenant scope в middleware.

Переходный период: для существующих таблиц ввод tenant_id идёт задачами блока MT ниже. Новые таблицы обязаны быть tenant-aware сразу.

Roadmap-сумма по приоритетам¶

Блок	Задач	Чистые часы	Календарь
P0 (безопасность, ротации)	6	~10 ч	~1 неделя
P1 MT (мультитенантность)	6	~85 ч	~4–5 недель
P1 CRM-17 (Postgres)	1	~30 ч	~2 недели
P1 CRM-документооборот и остальные	15	~200 ч	~10–12 недель
P1 INF-04, VAULT, RAG-04..05	4	~28 ч	~2 недели
Итого P0+P1	32	~355 ч	~5–6 месяцев
P2 (план после ядра)	22	~350 ч	~5–6 месяцев
P3 + Later	~50	не оценивается	по мере входа заказчиков

Ключевое: первые 5–6 месяцев уходят на закрытие P0+P1. Это ровно тот срок, о котором говорим инвестору в презентации («переход от прототипа боевой эксплуатации к промышленной»).

MT — мультитенантный контур платформы¶

P1¶

MT-02 · 24 ч / 6 дн · Добавить tenant_id во все ключевые таблицы CRM: objects, contracts, requests, estimates, invoices, acts, documents, object_contracts, crm_clients, assignments, materials_movements, users (через membership). Индексы (tenant_id, ...) на всех hot-path выборках. Тест: EXPLAIN подтверждает использование tenant-индекса.
MT-03 · 16 ч / 4 дн · Middleware/interceptor на backend, автоматически инжектирующий tenant_id в контекст запроса из сессии пользователя. Запретить прямой SQL/ORM-запрос к tenant-таблицам без tenant filter (проверка в тестах и линтере). Служебные фоновые задачи явно указывают tenant либо system.
MT-04 · 10 ч / 3 дн · Membership-таблица tenant_memberships(user_id, tenant_id, role, status): один пользователь может быть в нескольких тенантах с разными ролями. Пример: Роман — admin в ip-golovin, guest в тенанте заказчика. UI переключателя тенантов добавляется в MT-08.
MT-05 · 14 ч / 4 дн · Изоляция файлового хранилища по tenant: alatyr-storage-api получает tenant_id в токене, файлы уходят в путь /{tenant_slug}/{object_id}/..., кросс-tenant чтение возвращает 403. Совместимо с RAG-04.
MT-06 · 8 ч / 2 дн · Аудит доступа: любой tenant-cross запрос (админ платформы читает данные другого tenant) пишется в platform_audit_log с обоснованием. Требование для будущей ФСТЭК-аттестации.

P2¶

MT-07 · 12 ч / 3 дн · Тарифная модель тенанта: tenant_plans(tenant_id, plan_code, limits_json, valid_from, valid_to) с лимитами по объектам, пользователям, объёму хранилища и запросам к ИИ. Enforcement делается позже (MT-12), но модель фиксируется сейчас.
MT-08 · 10 ч / 3 дн · UI: переключатель тенанта в шапке для пользователей с membership в нескольких тенантах. Cookie/JWT хранят активный tenant_id; все ссылки и API-вызовы уже tenant-aware после MT-03.
MT-09 · 18 ч / 5 дн · Onboarding нового тенанта: страница «создать компанию» с автосозданием tenant, admin membership, seed данными (справочники, шаблоны документов, роли), выбором тарифа. Пока internal-only; публичный self-serve позже (MT-13).
MT-10 · 20 ч / 5 дн · Разделение справочников на глобальные и tenant-local: каталог МойСклад может быть общим (для тенантов, работающих с одним источником) или собственным; шаблоны документов, ставки мастеров, номенклатура работ — tenant-local с возможностью копирования из платформенного шаблона.
MT-11 · 14 ч / 4 дн · Изоляция ИИ-контекста и памяти агентов по tenant: role orchestrator (CRM-29) не должен путать данные между тенантами; каждый вызов агента получает tenant_id, promt-инъекции о других тенантах блокируются.

P3¶

MT-12 · 10 ч / 3 дн · Enforcement лимитов тарифа (MT-07): soft-warning при 80%, hard-block при 100%, счётчики использования в админке тенанта.
MT-13 · 30 ч / 8 дн · Публичный self-serve onboarding: регистрация нового тенанта без участия админа платформы. Требует MT-09, MT-12 и стабильных биллинговых потоков.
MT-14 · 20 ч / 5 дн · Экспорт данных тенанта (portable object passport): все объекты, договоры, документы, история одним архивом с сохранением связей. Требование для доверия корпоративных заказчиков.
MT-15 · 24 ч / 6 дн · Импорт данных тенанта из архива MT-14 в другой инстанс платформы (in-house установка заказчика).

Later¶

MT-16 · ~80 ч (крупный эпик) · On-premise инсталляция тенанта: развёртывание изолированного инстанса alatyr-service в контуре корпоративного заказчика с федеративной синхронизацией справочников. Требуется для КИИ и ФСТЭК-профилей.
MT-17 · ~40 ч · Кросс-tenant коллаборация: подрядчик-исполнитель одного тенанта работает на объекте заказчика-другого тенанта; управляемая шара конкретной карточки объекта с ограниченными правами.

INF — общая инфраструктура¶

P0¶

INF-01 · 3 ч / 1 дн · Убрать повседневный SSH под root на VPS: отдельный администратор с sudo, Ed25519 с passphrase, проверка Hostkey Web Console, затем запрет парольного SSH-входа root.

P1¶

INF-04 · 12 ч / 4 дн · Второй VPS в российской юрисдикции (Hostkey RU / Selectel / Timeweb) как staging/DR-контур: даже пустой — снимает вопрос КИИ на встречах с корпоративными заказчиками и служит целью миграции продакшена. Настройка по стандарту INF-01, доступ через WireGuard.

P2¶

INF-05 · 4 ч / 1 дн · Вынести монитор status.alatyr-service.ru (Uptime Kuma) в отдельный GitHub-проект oswold1979/alatyr-status: docker-compose + nginx + аккумулирующие heartbeat-бэкапы (data-волюм в backup-таймер), README со списком мониторингов и status page URL, deploy через GitHub Actions по push в main (аналогично alatyr-service). Цель: конфигурация под версионным контролем, прозрачный деплой, backup/restore через стандартный пайплайн, возможность восстановить статус-монитор на другой машине в один docker-compose up.

P3¶

INF-02 · ~40 ч (пилот) · Вернуться к Zabbix: определить внутренний и клиентский контуры, размещение сервера, доступ через VPN, первые шаблоны и границу с Uptime Kuma. Начать с read-only пилота.

Later¶

INF-03 · оценивается перед закупкой · Заменить ragserver на машину с GPU не менее 12 GB VRAM. Целевая конфигурация: ragserver-workstation.md.

CRM — alatyr-service¶

Все новые CRM-задачи выполняются в tenant-aware режиме. Существующие задачи ниже сохраняют исходные ID; там, где реализация зависит от MT, добавлено пояснение.

P0¶

CRM-01 · 1 ч · Ротировать STORAGE_API_TOKEN между alatyr-service и alatyr-storage-api, обновить Vaultwarden и проверить старый/новый токены без публикации значений.
CRM-02 · 1 ч · Сменить или подтвердить действующий admin-пароль alatyr-service. Секрет в KB не записывать.

P1¶

P2¶

P3¶

Later¶

TAV — alatyr-taverna¶

P2¶

TAV-01 · 2 ч (решение, не разработка) · Определить судьбу проекта: пауза, ограниченный бэклог, перенос в бренд-вселенную alatyr-service или архивирование.

Later¶

TAV-02 · ~10 ч · Настроить autodeploy по готовому runbook. Выполнять только если по TAV-01 решено продолжать проект.

DEF — DeFi-анализатор¶

Later¶

DEF-01 · ~8 ч · Прочитать и утвердить ТЗ defi-analyzer-spec.md, ответить на вопросы и зафиксировать приоритеты.
DEF-02 · ~80 ч (крупный эпик) · Backend-сканер: источники DEX, gas/fee/slippage, ликвидность, валидность цен и API. Блокируется DEF-01.
DEF-03 · ~40 ч · Веб-интерфейс пятиминутного окна сигналов. Блокируется DEF-01 и DEF-02.

VAULT — Vaultwarden¶

P1¶

VAULT-01 · 4 ч / 1 дн · Настроить off-site бэкап по runbook: SSH-ключ, конфигурация и регулярный запуск.
VAULT-02 · 2 ч · Выполнить изолированный test restore по runbook, проверить вход и одну запись. После VAULT-01.

P2¶

VAULT-03 · 3 ч / 1 дн · Настроить SMTP через Yandex 360 по runbook и проверить отправку.

RAG — RAG-платформа¶

P0¶

RAG-01 · 2 ч · Ротировать пароль Linux-пользователя oswold на ragserver и заменить во всех местах повторного использования. Новое значение не отправлять в чат.
RAG-02 · 1 ч · Ротировать QDRANT_API_KEY и обновить Vaultwarden.
RAG-03 · 2 ч · Ротировать POSTGRES_PASSWORD через ALTER USER, обновить .env, перезапустить и проверить сервисы.

P1¶

RAG-04 · 12 ч / 3 дн · Изоляция знаний в двух измерениях: tenant_id + object_id. Отдельные коллекции или обязательный metadata filter {tenant_id, object_id} + tenant ACL и object ACL. Запрет общей клиентской коллекции; negative tests на кросс-tenant и кросс-object утечку. Согласовано с MT-05 и MT-11.
RAG-05 · 6 ч / 2 дн · Настроить бэкап /opt/rag-platform/data/, pg_dump, Qdrant snapshots и OpenWebUI data по runbook.

P2¶

RAG-06 · 30 ч / 8 дн · Extraction/OCR lifecycle: preflight, таблицы, provenance, версии, синхронное удаление оригинала и вектора, контроль полноты индексации. Provenance включает tenant_id.
RAG-07 · 20 ч / 5 дн · Provider-neutral model router с policy по роли, данным, сложности и бюджету; без тихого cloud fallback.
RAG-08 · 24 ч / 6 дн · Evaluation и мониторинг retrieval/index качества RAG: эталонные вопросы, citations, stale-sync, latency/error/cost и adversarial документы. Включает adversarial tests на попытку получить данные другого tenant.
RAG-09 · 10 ч / 3 дн · Создать приватный репозиторий alatyr-rag-platform из sanitized шаблонов. Перед публикацией выполнить RAG-02 и RAG-03; секреты не коммитить.

P3¶

RAG-10 · 4 ч / 1 дн · Пилот загрузки файла с knowledge_id в metadata по runbook. Не выполнять без отдельного указания владельца.

Не включено¶

Внешние временные ссылки на документы: клиент получает документы через личный кабинет.
Отдельная миграция старых документов в единый реестр: пока преждевременно.

Changelog¶

2026-08-27 (поздний вечер): Добавлена INF-05 (P2) — вынести монитор status.alatyr-service.ru (Uptime Kuma) в отдельный GitHub-проект oswold1979/alatyr-status с docker-compose, GitHub Actions deploy и аккумулирующими backup’ами data-волюма.
2026-08-27 (поздний вечер): Закрыт эпик MT-01 — alatyr-service PR #99 смержен (323a675), production deploy 33074178032 успешен, prod healthcheck HTTP 200. Создана таблица tenants (ULID id, slug UNIQUE, kind enum, status enum, created_at INTEGER), в базе автоматически появились 2 тенанта (golovin, korobochka) через идемпотентный seed 1:1 из own_companies. Read-only модуль server/tenants.ts, 6 smoke-тестов в CI. Спека multitenancy-spec.md обновлена до v0.2: created_at ISO-8601 → INTEGER unix epoch (единообразно с остальными таблицами), repository → feature-модуль, миграция через inline CREATE TABLE IF NOT EXISTS (проектная идиома). Следующий шаг — MT-02 (tenant_id в hot-path таблицы CRM).
2026-08-27 (поздний вечер): добавлена CRM-64 — в карточке клиента не отображается ИИ-панель, хотя код был написан 26.08.2026. Разобраться самому, добавить smoke-test против регрессии. В репозиторий выложен снимок предыдущей версии TODO как TODO-2026-08-27.md.
2026-08-27 (вечер): введён эпик MT — мультитенантный контур как архитектурный якорь платформы. CRM-50 и CRM-62 формально перенесены в MT-01..06 и MT-13. CRM-17 (миграция SQLite → Postgres) поднята с P2 в P1 как техническая предпосылка мультитенантности. RAG-04 расширена до двухмерной изоляции (tenant + object). Добавлен раздел «Архитектурный принцип: multi-tenant by default» с запретом писать новые CRM/RAG-объекты без tenant_id. Добавлен INF-04 — второй VPS в российской юрисдикции как staging/DR-контур, снимающий вопрос КИИ на переговорах. Ко всем активным задачам добавлены грубые оценки чистых часов и календарных дней.
2026-08-27: CRM-63 закрыта: PR #98 смержен (e4c3a90), production deploy 33043447836 успешен. На VPS установлен ежедневный проверяемый SQLite backup с 30-дневным retention; первый backup и изолированный restore-check выполнены deployment workflow.
2026-08-27: CRM-63 подготовлена в alatyr-service PR #98 (34540eb): WAL-safe backup, обязательный SHA-256 manifest, изолированный restore-check, ежедневный systemd timer, сохранение DB/WAL/SHM при аварийном rollback и CI smoke-test; ручной Build 33024805125 успешен. Production deploy не выполнялся.
2026-08-27: добавлена CRM-63: ежедневный проверяемый backup/restore SQLite поднят в P1, а миграция PostgreSQL CRM-17 перенесена в P2 как стратегически обязательная, но не аварийная задача.
2026-08-27: TODO полностью пересобран по проектам и приоритетам. 83 исходные активные позиции получили стабильные ID INF-01..03, CRM-01..62, TAV-01..02, DEF-01..03, VAULT-01..03, RAG-01..10; добавлена таблица миграции старых ID. Явно разведены бизнес-требования и техническая реализация документооборота, внутренний пилот Zabbix и коммерческая услуга, CRM evaluation и RAG retrieval evaluation. Исторические файлы не перенумеровывались.
2026-08-27: программа единого документооборота одобрена; фаза 1 для object_contracts завершена PR #97 (00bbbaa) и production deploy 33021301456. Контрольные запросы к RAG и МоёДело не выполнялись.
2026-08-27: задача 20260721-7 закрыта PR #96; добавлены подсказки о незаполненных полях при переводе заявки в объект.
2026-08-27: ежедневный дайджест Alatyr KB ba645ae6 отключён и не должен создаваться повторно без отдельного решения владельца.