Концепция «Алатырь» — от текущего состояния к идеальной картине¶

Актуально на: 29.08.2026 Статус: вторая версия, включены базовые принципы организации работы и KB-сайт Периметр: магистральное направление — платформа alatyr-service и её инфраструктура; фундамент, на котором уже сейчас идут первые продажи и постепенно наращиваются услуги

Базовые принципы организации¶

Эти принципы выше конкретных проектов и этапов. Из них следует вся архитектура и порядок работ.

Принцип 1. Инфраструктура — это фундамент, не проект. Локальный RAG, VPS+WireGuard, Vaultwarden, сама база знаний — обслуживают все бизнес-проекты одновременно. Они не в одном ряду с проектами, а под ними.

Принцип 2. Проект — единица бизнес-смысла, не юрлицо и не окончательная категория. Проекты живые: рождаются, растут, сливаются друг с другом, дробятся, уходят в дремлющее состояние. Кожа сегодня активный проект, завтра — раздел эко-фермы. Стройка возможно когда-то сльется с Alatyr Service. Интерес к фехтованию может вырасти в услугу на эко-ферме. Архитектура должна поддерживать такие движения без переписывания.

Принцип 3. Юрлица — инструмент оформления, не проекты. ИП Головин Р.Ю., ИП Головин А.Р. (Коробочка), будущие ООО — способы легально проводить работы и деньги через проекты. Один проект может использовать несколько юрлиц, одно юрлицо — несколько проектов. На сайте юрлица — справочник, не узел навигации.

Принцип 4. Продажи не ждут завершения архитектуры. Магистраль — фундамент, на котором первые продажи уже идут. Каждый новый этап расширяет ассортимент услуг, но продажи не останавливаются.

Принцип 5. Слои не разгоняются неравномерно. Нельзя делать маркетплейс на неполном паспорте, продавать мониторинг без ИИ-диспетчера, заводить внешних тенантов до MT-02..06. Каждый этап работает на следующий, а не в конкуренции с ним.

Идеальная картина через 24 месяца¶

Есть техническая платформа для управления жизненным циклом инженерных объектов, которая одновременно является операционным ядром внешней технической службы. На платформе живут:

Сам основатель как первый и главный тенант — ИП Головин Р.Ю. со своим портфелем объектов
ИП Головин А.Р. (Коробочка) как второй юридический контур внутри платформы
Внешние тенанты — небольшие региональные подрядчики без своей IT-инфраструктуры, использующие Алатырь как SaaS для собственных объектов
Корпоративные заказчики с изолированным контуром на отдельном тенанте под их конкретный профиль безопасности

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

Платформа продаёт два коммерческих контура поверх паспорта:

Контур мониторинга и реакции. Платформа наблюдает за системами объекта, автоматически классифицирует события через ИИ-агента, эскалирует по регламенту (собственник, диспетчерская, экстренные службы, лицензированный партнёр ГБР). Абонентка 5–25 тыс. ₽/мес с объекта, маржа высокая — предельные затраты на следующий объект малы.

Контур маркетплейса работ. Заявка на плановую или срочную работу распределяется в пул исполнителей — собственная бригада или партнёрский подрядчик. Исполнитель получает не звонок, а карточку с полным паспортом. Платформа удерживает 20–35% с работы, обеспечивает документооборот заказчика, гарантирует качество независимо от того, какая бригада поехала.

Оба контура работают синергично: мониторинг создаёт заявки для маркетплейса.

Дополнительные линии услуг нарастают поверх стабильного фундамента: - Мониторинг IP-инфраструктуры и удалённое администрирование серверов, роутеров, СХД - ИИ-агенты ролей (секретарь, сметчик, делопроизводитель) как отдельная услуга - Активный мониторинг охранной и пожарной сигнализации как премиальный слой абонентки - On-premise инсталляция для корпоративного заказчика в его собственном контуре

Целевая экономика на 24 месяце: портфель 25–50 объектов на постоянном обслуживании собственной командой + 3–5 крупных пилотов; 5–10 партнёрских исполнителей в пуле; несколько внешних SaaS-тенантов. Годовой оборот платформы порядка 20–40 млн ₽ базово, 40–60 млн ₽ при масштабировании SaaS-контура.

Что уже есть сегодня (август 2026)¶

Это не «предстоит сделать», это работающий фундамент, на котором строится всё остальное:

Публичная витрина alatyr-service.ru с тремя посадочными: техническая служба для бизнеса, обслуживание видеонаблюдения, приёмка существующих систем на обслуживание
Гостевой checkout без регистрации, оплата через ЮKassa на ИП Коробочка, чеки, доставка
CRM-контур с четырьмя ролями (admin, manager, master, client), заявками, объектами, договорами, счетами, актами
Двусторонняя синхронизация счетов и актов с «Моё Дело», автоматический импорт объектов и контрагентов, автозаполнение реквизитов через ЕГР по ИНН
Каталог МойСклад с 142 услугами, резервированием остатков, гостевым checkout
Объект как workspace с вкладками договоров, материалов, версий проектов, писем и журнала работ
Единый жизненный цикл документов, фаза 1 — архивирование, восстановление, редактирование метаданных, каскадное удаление с блокировкой при финансовых зависимостях
ИИ-контур объекта — RAG-ассистент, привязанный к объекту, с изоляцией знаний; Ollama-worker извлекает из PDF/DOCX ключевые условия договоров в черновик с подтверждением оператором
Собственная инфраструктура — alatyr-storage-api на ragserver, nginx + AmneziaWG + Bearer-токен, файлы клиентов не уходят в сторонние облака
Проверяемые SQLite-бэкапы с WAL-safe snapshot, SHA-256 manifest, изолированным restore-check в CI, ежедневным systemd timer, 30-дневным retention
Мультитенантный якорь (MT-01) — таблица tenants, ULID id, seed 1:1 из own_companies, read-only API агента
Приватная инфраструктурная база знаний alatyr-infra-kb как единый источник правды для агентов, RAG и Obsidian

Три слоя платформы, из которых складывается идеал¶

Концепция удобно раскладывается на три слоя. Каждый слой имеет свой этап зрелости и своё время выхода в production.

Слой 1. Данные объекта (паспорт как ядро)¶

Всё остальное строится на этом слое. Пока паспорт не полный и не переносимый — ни маркетплейс, ни внешние тенанты, ни on-premise не работают.

Что входит: трёхслойная модель данных объекта (запроектировано / смонтировано / эксплуатируется сейчас), реестр оборудования и его расположения, схемы кабельных линий, доступы, история инцидентов, дефектная ведомость, регламент обслуживания, версии проектов, финансовая история, документы объекта.

Идеал: любой объект можно экспортировать одним архивом и импортировать в другой инстанс платформы без потерь.

Текущее состояние: ~70% готовности. Основа есть (карточка объекта, договоры, материалы, документы, версии проектов, финансовая сводка), но нет полного паспорта в едином файле и переносимости между тенантами.

Слой 2. Операционный контур (что делается вокруг паспорта)¶

Как объект живёт день ото дня после приёмки: заявки, работы, документы, отчётность.

Что входит: заявка → объект → договор → смета → счёт → акт с автосинхронизацией в «Моё Дело»; управление исполнителями (свои и партнёры) с назначением на объект, ставками, сменами, начислениями; работа с материалами по движению; управление кабинетами клиентов и мастеров.

Идеал: любая работа проходит по единой цепочке от заявки до акта; исполнитель получает полный контекст; клиент видит статус в своём кабинете.

Текущее состояние: ~60% готовности. Цепочка работает end-to-end для одного тенанта, но нет ещё маркетплейсной маршрутизации, регламента реакции, назначения на партнёров, поля мастера в мобильном интерфейсе.

Слой 3. Коммерческие контуры (как платформа зарабатывает)¶

Модель монетизации: два контура + вспомогательные услуги.

Что входит: контур мониторинга и реакции; контур маркетплейса работ; SaaS для внешних тенантов; корпоративный on-premise-контур; дополнительные линии услуг (IP-мониторинг, ИИ-агенты как услуга, активный мониторинг тревог, оцифровка, VPS-инфраструктура для клиента).

Идеал: предсказуемая MRR-модель поверх абонентки + прозрачная маркетплейсная комиссия + понятная SaaS-цена для партнёрских тенантов.

Текущее состояние: ~15% готовности. Есть техническая основа для оплаты, но сами продуктовые пакеты (мониторинг, реакция, маркетплейс) как коммерческие услуги не оформлены. Внутренне ясно, что́ делаем, — снаружи это ещё не покупается.

Этапы: от текущей точки к идеалу¶

Этапы построены как лестница созревания слоёв. Каждый следующий этап опирается на закрытые предыдущие. Внутри этапа задачи выполняются параллельно, между этапами — последовательно.

Этап 0. Стабилизация текущего контура (сентябрь 2026)¶

Цель: снять критический технический долг и мелкие регрессии, чтобы дальше не тормозило.

Что делаем: - Ротация всех унаследованных секретов (пароли Linux, Qdrant, PostgreSQL, токены) - Разбор и починка CRM-64 (в карточке клиента не отображается ИИ-панель) - Второй VPS в российской юрисдикции как staging/DR-контур (INF-04) — снимает вопрос КИИ на переговорах и даёт безопасное место для крупных изменений - Финальная сборка руководства по эксплуатации в alatyr-infra-kb

Метрика выхода: нет P0-задач, нет критичных регрессий, есть второй VPS.

Оценка: ~15 часов чистой работы, ~1–1.5 недели календаря.

Этап 1. Завершение паспорта объекта и мультитенантности (сентябрь–октябрь 2026)¶

Цель: довести слои 1 и 2 до состояния, когда любую новую задачу можно писать в архитектуре мультитенантности без страха переписки.

Что делаем: - MT-02..MT-06: разнос tenant_id по CRM-таблицам, tenant middleware, membership, изоляция файлов, аудит - CRM-17: миграция SQLite → PostgreSQL как техническая предпосылка мультитенантности - Единый жизненный цикл документов, фазы 2..N: договоры → допники → счета → акты → сметы в единой связной цепочке с версионированием - CRM-документооборот: заявки → объект переход с explanations, автоматический перевод после оплаты, финансовая сводка - RAG-04: двухмерная изоляция знаний (tenant_id + object_id)

Метрика выхода: MT-02..MT-06 в архиве; можно завести второй тенант без миграции данных; PostgreSQL в production; RAG-знания изолированы по объекту и тенанту.

Оценка: ~130 часов чистой работы, ~7–9 недель календаря.

Параллельно идут первые платные продажи текущему тенанту (ИП Головин Р.Ю.) — платформа боевая, продажи не ждут завершения архитектуры.

Этап 2. Контур мониторинга и реакции как коммерческий продукт (октябрь–декабрь 2026)¶

Цель: контур 1 монетизации становится продаваемой услугой с прозрачной ценой и договором.

Что делаем: - Модуль активного мониторинга инженерных систем: сетевая доступность, статус потока видеокамер, целостность архива, статус тревог, состояние резервного питания - Регламент событий: справочник типов событий, правила эскалации, каналы уведомлений (email/Telegram/SMS/звонок) - ИИ-агент диспетчерского слоя: автоматическая классификация события, выбор канала реакции, подтверждение оператором для эскалации к внешним службам - Договор мониторинга + прайс + типовые SLA-пакеты - Партнёрство с лицензированным охранным предприятием под ГБР для реагирования (внешнее соглашение, не разработка) - Внутренняя приборная панель мониторинга (dashboard всех объектов на обслуживании)

Метрика выхода: можно продать контур мониторинга новому клиенту, подписать договор и запустить наблюдение за 1 неделю.

Оценка: ~150 часов чистой работы + партнёрские переговоры, ~10–14 недель календаря.

Этап 3. Контур маркетплейса работ (январь–март 2027)¶

Цель: контур 2 монетизации — заявки на работы распределяются в пул исполнителей по паспорту объекта.

Что делаем: - Управление пулом исполнителей: профили внешних подрядчиков (ИП, самозанятые), специализации, географическая привязка, история работ, рейтинг - Правовая рамка: платформа как агент между заказчиком и исполнителем (агентский договор, комиссия), либо платформа как заказчик работ у подрядчика (собственный договор + перепродажа заказчику) - Модуль назначения заявки: правила распределения (география, специализация, загрузка, рейтинг), возможность аукциона или прямого назначения - Мобильный интерфейс исполнителя: получение задачи, паспорт объекта, чеклист работ, фото-подтверждение выполнения, время - Финансовый контур: удержание комиссии, автоматические выплаты исполнителям, документооборот с ФНС (агентские схемы для самозанятых, чеки, отчёты) - Приёмка работ клиентом: акт от платформы, рейтинг исполнителя

Метрика выхода: первый партнёрский исполнитель получает и закрывает заявку через платформу с автоматическим удержанием комиссии.

Оценка: ~200 часов чистой работы + юридические согласования, ~14–18 недель календаря.

Этап 4. Внешние тенанты и корпоративный контур (март–июнь 2027)¶

Цель: платформа продаётся не только своим объектам, но и партнёру или корпоративному заказчику как SaaS с изолированным контуром.

Что делаем: - MT-07..MT-11: тарифная модель тенанта, UI переключателя, onboarding нового тенанта, разделение справочников на глобальные и tenant-local, изоляция ИИ-контекста по тенанту - Публичный self-serve onboarding (MT-13): страница «создать компанию», автосоздание тенанта, seed данными, выбор тарифа - Аттестация ФСТЭК под профиль корпоративного заказчика (внешняя процедура, не разработка) — при появлении конкретного корпоративного клиента - On-premise-инсталляция как отдельный конфигурационный контур с документированным разворачиванием у заказчика

Метрика выхода: второй тенант завёден на платформе (партнёрский подрядчик или пилотный корпоративный заказчик) и оплачивает подписку.

Оценка: ~180 часов чистой работы + корпоративные переговоры, ~12–16 недель календаря.

Этап 5. Дополнительные линии услуг (параллельно, с этапа 2)¶

Цель: нарастить портфель услуг поверх основных контуров без риска для магистрали.

Что делаем (по мере входа реального спроса): - Мониторинг IP-инфраструктуры и удалённое администрирование как отдельный SKU - ИИ-агенты ролей (секретарь, сметчик, делопроизводитель) как отдельные подписки внутри тенанта - Оцифровка документов, архивная работа - VPS-инфраструктура и настройка удалённого доступа для клиента как отдельный продукт под ИП Головин Р.Ю. - Услуги ИП Коробочка (частный сектор: «Дом 4 камеры», «Офис под ключ», печать, реставрация) как отдельная витрина, использующая ту же платформу через второй тенант

Оценка: отдельно по каждой услуге при её запуске.

Ключевой принцип последовательности¶

Не разгонять слои неравномерно. Ошибка была бы делать маркетплейс на неполном паспорте, продавать мониторинг без ИИ-диспетчера или заводить внешних тенантов до закрытия MT-02..MT-06. Каждый этап работает на следующий, а не в конкуренции с ним.

Продажи не ждут завершения архитектуры. Магистраль — это фундамент, на котором первые продажи уже идут (текущий тенант ИП Головин Р.Ю. работает с реальными объектами). Каждый новый этап расширяет ассортимент того, что можно продать, — но продажи не останавливаются.

KB-сайт как операционный центр всей работы¶

Концепция, этапы, задачи и видение проектов ливут в едином месте — локальной базе знаний (KB) на ragserver, доступной через WireGuard. Сайт строится из репозитория alatyr-infra-kb через MkDocs Material, правки — через Decap CMS с автокоммитом в git. RAG-контур видит все правки через существующий sync-скрипт.

Структура главной страницы сайта:

Фундамент — RAG-платформа, VPS+WireGuard, Vaultwarden, сама KB
Стратегия — концепция (этот документ), roadmap, этапы
Проекты — активные и долгосрочные, перемещаемые между группами и друг в друга
Личное — финансы, здоровье, интересы
Справочники — юрлица и другие статические данные

Структура проекта: - index.md — видение, статус, зависимости от инфраструктуры, юрлицо-исполнитель в frontmatter - Подразделы для крупных проектов (например Alatyr Service: CRM, MT, RAG, INF, документооборот) - tasks/ — каждая задача в отдельном файле с ULID + алиасом - tasks.md генерируется автоматически при сборке сайта для показа всего списка

Идентификаторы задач: ULID как стабильный внутренний ключ + человекочитаемый алиас (CRM-64, KOZHA-05) для отображения. При переносе задачи между проектами алиас регенерируется, ULID остаётся.

CMS-возможности через Decap: - Кнопка «+ Новая задача» с формой (название, оценка, приоритет, чекбокс выполнения) - Кнопка «+ Новый проект» с автосозданием директории и включением в навигацию - Inbox для быстрых идей — одно поле, автосохранение с датой - Отметка чекбокса в один клик коммитит в git - Редактирование любой страницы через веб без git-знаний

RAG-интеграция по этапам: - Сейчас: Пассивная индексация через sync-to-openwebui.sh, RAG видит все правки автоматически - После запуска сайта: Виджет «спросить у ИИ» на страницах проектов с фильтрацией по проекту - В перспективе: Двусторонняя интеграция, RAG предлагает задачи на основе анализа истории сессий и коммитов

Сама реализация KB-сайта входит в Этап 0 как отдельная задача INF-05 с оценкой ~15 часов. До выполнения INF-05 задачи всех этапов ведутся в текущем TODO.md; после — переезжают в новую файловую структуру projects/*/tasks/.

Как это отражается в TODO¶

TODO переорганизуется в два шага.

Шаг 1 (сейчас). Пока KB-сайта нет, TODO остаётся в едином TODO.md, но задачи получают тег этапа ([Этап 0], [Этап 1], ...) в дополнение к приоритету. P0-задачи все уходят в Этап 0, MT-эпик распределяется между Этапом 1 и Этапом 4. Добавляются заготовки задач для Этапа 2 (мониторинг+реакция), Этапа 3 (маркетплейс) и INF-05 (KB-сайт). Задачи из P3 и Later, не попадающие ни в один этап, помечаются как «вне текущего roadmap».

Шаг 2 (после выполнения INF-05). Задачи переезжают в новую файловую структуру projects/*/tasks/*.md, каждая в отдельном файле. TODO.md остаётся как legacy-вид с автогенерацией из файлов задач для RAG и чтения без сайта.

Что этот документ не решает¶

Специально не входит в концепцию, чтобы не размывать магистраль:

DeFi-анализатор (DEF-01..03) — отдельный проект, живёт своим циклом
Alatyr Taverna — соседний бренд, не пересекается с сервисной платформой
Vaultwarden — инфраструктурный инструмент, не продуктовое направление
Строительный контур ИП Головин Р.Ю. (низковольтка) — денежный источник, отдельный от платформы, но продолжает работать как двигатель денежного потока и источник кейсов
Земля и эко-ферма/глэмпинг — долгосрочный проект вне текущего roadmap

Все они остаются в общей бизнес-системе, но не влияют на порядок задач в alatyr-service.