Documentation Master Plan — Project 15 Structure Snapshot
Версия: 1.0
Дата: 23.04.2026
Статус: Готов к обсуждению
Назначение
Этот документ является опорным master-plan для развития документации проекта vitiana-api-platform.
Он фиксирует исходную структуру проектного плана 15 и задаёт документарный контур работы:
- какие тематические области должны быть покрыты документацией платформы;
- какие архитектурные, операционные, доменные и интеграционные вопросы нельзя оставить неописанными;
- как соотносить текущие и будущие документы
vitiana-api-platformс исходным проектным каркасом.
Этот документ не заменяет архитектурные, reference-, operations- и development-документы проекта. Его роль — быть картой полноты и опорным концептом для развития полного цикла документации платформы.
Источник снапшота
- Локальный снимок структуры проекта
projects/15по состоянию на2026-04-23. - Исходный материал фиксировал только структуру
section → checklist → itemв видеid + name. - Источник исходного снапшота: live database
ga509228_checklist.
Как использовать этот документ
- При развитии документации
vitiana-api-platformиспользовать этот master-plan как карту обязательных тем покрытия. - Ни один source section, checklist или item из зафиксированной структуры не должен быть silently omitted из целевого документарного контура.
- В итоговом состоянии документация платформы должна дать содержательный ответ на каждый вопрос, который зафиксирован в этом плане, даже если ответ распределён между несколькими документами.
- Новые документы и разделы создавать не в корне проекта, а в соответствующих разделах:
overview/,reference/,operations/,development/. - Один пункт проектного плана не обязан соответствовать одному markdown-файлу; допустимо агрегировать связанные вопросы в более сильные концептуальные документы.
- Если тематическая область уже покрыта существующей документацией, развивать и уточнять текущие документы вместо создания дублей.
- Если структура проектного плана меняется, сначала обновлять реальный источник, затем этот master-plan, затем производные архитектурные документы.
Логика разнесения по разделам документации
overview/— общая концепция платформы, границы системы, высокоуровневая архитектура, карта домена.reference/— устойчивые технические контракты, схемы данных, слои системы, модели сущностей, правила интеграций.operations/— инфраструктура, deployment, мониторинг, инциденты, эксплуатационные runbook-процессы.development/— roadmap, backlog покрытия, review-журналы, master-plan развития документации и проектные решения в развитии.
Project
15—VITIANA API PLATFORM
Sections
20—ПЛАТФОРМЕННАЯ ДОКУМЕНТАЦИЯ24—СИСТЕМА УПРАВЛЕНИЯ ПРОЕКТНОЙ ДОКУМЕНТАЦИЕЙ21—СЕРВЕРНАЯ И ИНФРАСТРУКТУРНАЯ СРЕДА22—ПРИКЛАДНАЯ И СИСТЕМНАЯ РАЗРАБОТКА23—АРХИТЕКТУРА ДАННЫХ И БАЗЫ ДАННЫХ25—ИНТЕГРАЦИИ И ВНЕШНИЕ КОНТРАКТЫ26—ДОМЕННАЯ МОДЕЛЬ И БИЗНЕС-ПРАВИЛА27—ПОЛЬЗОВАТЕЛИ, РОЛИ И ДОСТУП28—КАЧЕСТВО ДАННЫХ И GOVERNANCE29—КОММЕРЧЕСКАЯ МОДЕЛЬ И ЦЕНООБРАЗОВАНИЕ30—БЕЗОПАСНОСТЬ И COMPLIANCE31—ОПЕРАЦИОННОЕ УПРАВЛЕНИЕ И ПОДДЕРЖКА32—ПОИСК, ДОСТУПНОСТЬ И QUOTE PIPELINE33—TOUR BUILDER И СОСТАВ ПРОДУКТА34—КЛИЕНТСКИЕ ПОВЕРХНОСТИ И КАНАЛЫ35—ФОНОВЫЕ ПРОЦЕССЫ И ORCHESTRATION36—ТЕСТИРОВАНИЕ, QA И RELEASE MANAGEMENT37—ФИНАНСЫ, ОТЧЁТНОСТЬ И SETTLEMENT
Tree
20 — ПЛАТФОРМЕННАЯ ДОКУМЕНТАЦИЯ
-
40—Внутренняя архитектурная и проектная документация платформы138—Подготовить базовый комплект внутренней документации платформы в статусе Draft139—Описать целевую архитектуру системы, её основные слои и принципы взаимодействия140—Провести предварительную оценку эффективности и эксплуатационной устойчивости будущей инфраструктуры141—Подготовить финансовую модель проекта и обоснование общей стоимости разработки142—Подготовить прогноз затрат по серверной инфраструктуре, оборудованию и сетевой части143—Сформировать первичную roadmap проекта с этапами, зависимостями и контрольными точками144—Провести архитектурное обсуждение и зафиксировать решение о запуске разработки в рамках выбранной инфраструктурной модели
-
41—Внешние технические материалы по системам и поставщикам145—Проанализировать технические ограничения и особенности API STUBA для встраивания в целевую платформу146—Проанализировать технические ограничения и особенности API ETG для встраивания в целевую платформу147—Описать общие принципы маппинга внутренних сущностей платформы со сторонними API и supplier-моделями164—Исследовать возможные подходы к получению, хранению и обработке геоданных165—Исследовать возможные подходы к получению, хранению и обработке POI-данных168—Определить потенциальных поставщиков данных для данного слоя и зафиксировать их условия подключения и использования
24 — СИСТЕМА УПРАВЛЕНИЯ ПРОЕКТНОЙ ДОКУМЕНТАЦИЕЙ
47—Система создания, ведения и защищённой публикации документации169—Разработать концепцию системы управления проектной документацией170—Подготовить архитектурное решение по хранению, публикации и разграничению доступа к документации171—Определить и зафиксировать технологический стек системы документации
21 — СЕРВЕРНАЯ И ИНФРАСТРУКТУРНАЯ СРЕДА
42—Базовая инфраструктура и окружение первичной разработки148—На основе проектной документации выбрать и обосновать стартовую конфигурацию оборудования для разработки149—Выбрать хостинг-провайдера или инфраструктурную площадку под запуск платформы150—Согласовать финансовую и договорную модель взаимодействия с выбранным хостинг-провайдером151—Выполнить закупку или оплату стартовой серверной инфраструктуры152—Определить базовый дистрибутив ОС и runtime-окружение для проекта153—Выполнить первичную настройку серверного оборудования и базового окружения154—Развернуть и настроить стартовый технологический стек разработки
22 — ПРИКЛАДНАЯ И СИСТЕМНАЯ РАЗРАБОТКА
-
43—Технологический стек платформы155—На основании архитектурной документации определить технологический стек разработки по слоям платформы
-
45—Миграция и адаптация API-модулей156—Перенести модуль Stuba на новый стек с сохранением внешнего контракта и совместимости интеграции
-
46—Geo / POI слой и пространственные данные166—На основании проведённых исследований принять архитектурное решение по обработке Geo и POI данных167—Реализовать базовые глобальные сервисы и методы обработки Geo и POI слоя
23 — АРХИТЕКТУРА ДАННЫХ И БАЗЫ ДАННЫХ
44—Схемы данных и инфраструктура хранения157—Определить состав БД, схемы, зависимости и инфраструктурные надстройки на основании архитектурной документации158—Подготовить инфраструктурное решение по логическому и физическому разделению БД при росте нагрузки159—Спроектировать архитектуру справочных и классификационных данных160—Спроектировать архитектуру пользовательских данных161—Спроектировать архитектуру ключевых доменных сущностей платформы162—Спроектировать архитектуру геопространственного слоя163—Спроектировать архитектуру слоя POI-данных
25 — ИНТЕГРАЦИИ И ВНЕШНИЕ КОНТРАКТЫ
-
48—Реестр внешних систем и контрактов173—Зафиксировать полный список внешних систем, API и каналов обмена, которые входят в контур платформы174—Определить формат и границы контракта по каждой интеграции: данные, методы, ограничения и частоту обмена175—Зафиксировать правила версионирования и обратной совместимости внешних контрактов
-
49—Надёжность интеграций и деградация сервисов176—Определить политику timeout, retry и ограничений по вызовам внешних API177—Описать сценарии деградации платформы при недоступности поставщиков и внешних сервисов178—Определить требования к логированию, мониторингу и ручной диагностике интеграционных ошибок
26 — ДОМЕННАЯ МОДЕЛЬ И БИЗНЕС-ПРАВИЛА
-
50—Канонические сущности платформы179—Определить базовый состав доменных сущностей платформы и границы ответственности каждой сущности180—Зафиксировать каноническую модель для property, room, offer, booking и связанных сущностей181—Развести master-data, справочные данные и оперативные данные по уровням хранения и обновления
-
51—Жизненный цикл продукта и бронирования182—Описать жизненный цикл оффера от загрузки данных до продажи или архивирования183—Описать жизненный цикл бронирования, включая промежуточные, ошибочные и отменённые состояния184—Определить, какие данные и события считаются источником истины для цены, доступности и статуса брони
27 — ПОЛЬЗОВАТЕЛИ, РОЛИ И ДОСТУП
-
52—Учётные записи и типы участников185—Определить типы пользователей и участников платформы: internal team, agency, partner, client186—Зафиксировать модель учётной записи, профиля и связей пользователя с агентством или партнёром187—Определить границы tenant-модели: что изолируется по агентству, партнёру или внутреннему контуру
-
53—Роли и права доступа188—Описать роли, зоны ответственности и базовые permission-set для каждой категории пользователей189—Определить правила доступа к API, данным и действиям на уровне ролей и контекста190—Зафиксировать требования к audit trail по действиям пользователей, партнёров и внутренних операторов
28 — КАЧЕСТВО ДАННЫХ И GOVERNANCE
-
54—Matching и управление качеством данных191—Определить правила matching, merge и разрешения конфликтов между данными разных поставщиков192—Определить критерии качества данных и обязательные проверки перед публикацией в рабочий контур193—Зафиксировать подход к ручной модерации, review-очередям и исправлению спорных данных
-
55—Происхождение и управление изменениями данных194—Определить, как хранится происхождение каждого ключевого поля и источник его последнего обновления195—Описать правила приоритета источников данных и переопределения значений внутри платформы196—Определить журнал изменений по критичным данным и правила отката ошибочных обновлений
29 — КОММЕРЧЕСКАЯ МОДЕЛЬ И ЦЕНООБРАЗОВАНИЕ
-
56—Цены и расчёт финальной стоимости197—Определить состав цены: source price, markup, fee, commission, discount и финальная стоимость198—Зафиксировать правила округления, валютной конвертации и расчёта итоговой цены для разных рынков199—Определить, в какой момент цена считается подтверждённой для клиента, агента и внутренней системы
-
57—Коммерческие правила и предложения200—Описать модель коммерческого предложения, срок его жизни и условия пересчёта201—Определить правила индивидуальных ценовых условий для партнёров, агентств и каналов продаж202—Зафиксировать принципы пересчёта цены при изменении supplier data, валюты или состава услуги
30 — БЕЗОПАСНОСТЬ И COMPLIANCE
-
58—Аутентификация и защита доступа203—Определить модель аутентификации для внутренних пользователей, партнёров и внешних клиентов204—Зафиксировать подход к управлению секретами, API keys, service credentials и их ротации205—Определить требования к защите сессий, токенов, rate limiting и базовым anti-abuse мерам
-
59—Персональные данные и аудит206—Определить состав чувствительных данных и правила их хранения, маскирования и удаления207—Зафиксировать требования к журналированию security-событий и действиям с критичными данными208—Определить базовые требования compliance, retention и доступа к персональным данным
31 — ОПЕРАЦИОННОЕ УПРАВЛЕНИЕ И ПОДДЕРЖКА
-
60—Мониторинг и инциденты209—Определить набор обязательных технических и бизнес-метрик для мониторинга платформы210—Зафиксировать правила алертинга и пороги срабатывания по критичным компонентам и интеграциям211—Подготовить базовые runbook-сценарии для типовых инцидентов и деградации сервиса
-
61—Поддержка и ручные операции212—Определить перечень ручных операционных действий, которые должны поддерживаться через admin-tools213—Зафиксировать сценарии ручной проверки, повторной обработки и восстановления проблемных данных214—Определить порядок эскалации, ответственности и журналирования при операционной поддержке
32 — ПОИСК, ДОСТУПНОСТЬ И QUOTE PIPELINE
-
62—Поисковый контур и выдача215—Определить сценарии поиска, которые платформа должна покрывать в первом рабочем контуре216—Зафиксировать состав поисковых параметров, фильтров и правил формирования выдачи217—Определить, какие данные в поисковой выдаче обязательны для клиента, агента и внутренних пользователей
-
63—Проверка доступности и quote pipeline218—Описать pipeline проверки availability и получения актуальной цены перед подтверждением предложения219—Определить правила повторной проверки данных при переходе от поиска к quote и от quote к бронированию220—Зафиксировать, какие этапы quote pipeline являются синхронными, а какие допускают фоновую обработку
33 — TOUR BUILDER И СОСТАВ ПРОДУКТА
-
64—Состав тура и пакетирование221—Определить, из каких компонент может состоять тур: проживание, перелёт, трансфер, страховка, услуги и допродажи222—Зафиксировать каноническую модель package и связи между его составными частями223—Определить обязательные ограничения и проверки совместимости компонентов внутри одного тура
-
65—Правила сборки и пересчёта тура224—Описать правила пересборки тура при изменении цены, доступности или состава компонентов225—Определить, какие версии тура и коммерческого предложения должны храниться в истории226—Зафиксировать правила расчёта итоговой стоимости, комиссии и служебных полей для собранного тура
34 — КЛИЕНТСКИЕ ПОВЕРХНОСТИ И КАНАЛЫ
-
66—B2B, B2C и partner surfaces227—Определить, какие сценарии и данные доступны в B2C, какие в B2B, а какие в partner API228—Зафиксировать различия по контрактам, правам и видимым данным между клиентскими каналами229—Определить минимальный состав пользовательских сценариев и экранов для каждого канала в MVP
-
67—Internal admin и рабочие интерфейсы230—Описать состав внутренних рабочих интерфейсов для операторов, менеджеров и службы поддержки231—Определить, какие действия должны быть доступны только через internal admin и не должны попадать во внешние каналы232—Зафиксировать требования к PDF, proposal output и служебным документам, которые формирует платформа
35 — ФОНОВЫЕ ПРОЦЕССЫ И ORCHESTRATION
-
68—Очереди, джобы и планировщики233—Определить перечень фоновых процессов: ingestion, sync, recalculation, notifications, cleanup и служебные джобы234—Зафиксировать, какие джобы запускаются по событию, какие по расписанию и какие вручную235—Определить требования к очередям, повторным попыткам, приоритетам и журналированию фоновых задач
-
69—Надёжность процессов и orchestration236—Описать правила идемпотентности, дедупликации и безопасного повторного запуска критичных процессов237—Определить точки orchestration, где требуется координация нескольких сервисов и источников данных238—Зафиксировать подход к наблюдаемости и диагностике долгих, зависших или частично выполненных процессов
36 — ТЕСТИРОВАНИЕ, QA И RELEASE MANAGEMENT
-
70—Стратегия тестирования и QA239—Определить стратегию тестирования по уровням: unit, integration, contract, regression и end-to-end240—Зафиксировать перечень критичных бизнес-сценариев, которые должны быть покрыты до выхода в рабочий контур241—Определить требования к тестовым данным, тестовым поставщикам и безопасным mock-стендам
-
71—Релизы, окружения и контроль изменений242—Определить модель окружений, правила продвижения изменений и состав release gates243—Зафиксировать порядок релизов, rollback, hotfix и контроля изменения внешних контрактов244—Определить требования к release notes, change log и формальному подтверждению готовности релиза
37 — ФИНАНСЫ, ОТЧЁТНОСТЬ И SETTLEMENT
-
72—Финансовый контур и взаиморасчёты245—Определить точки возникновения финансовых обязательств, начислений и удержаний внутри платформы246—Зафиксировать модель settlement между платформой, поставщиком, агентством и другими участниками цепочки247—Определить, какие финансовые события должны фиксироваться как первичные для последующей отчётности
-
73—Отчётность, аналитика и контроль маржи248—Описать обязательные отчёты по продажам, отменам, марже, комиссиям и качеству операционного контура249—Определить разрезы аналитики, которые должны быть доступны менеджменту, finance и операционной команде250—Зафиксировать правила расчёта маржи и контрольных метрик, по которым оценивается устойчивость бизнес-модели