Аудит документации платформы lovii — отчёт¶
DOCUMENTATION AUDIT REPORT
Аудит документации платформы lovii
Сквозная сверка корпуса из 70 страниц: неточности, несоответствия, приоритеты исправлений
- Объект: bestdeejay-design.github.io/lovii-crm
- Глубина: полный корпус, 11 разделов, ~550 тыс. знаков
- Метод: 4 трека извлечения фактов + автоматические проверки
- Дата отчёта: 10 октября 2026 г.
- Подготовлено: Super Z Audit
- Ревизия №1 внешнего аудита
Содержание
-
- Резюме аудита
-
- Объект, объём и методика аудита
-
- Критические несоответствия
-
- Противоречия между документами по темам
-
- Фактические неточности в академических разборах
-
- Структурные и формальные проблемы
-
- Проверено и подтверждено
-
- Приоритетный план исправлений
-
- Приложение: статистика корпуса и сводка реестра
1. Резюме аудита¶
Проведён внешний сквозной аудит документации платформы lovii, опубликованной по адресу bestdeejay-design.github.io/lovii-crm. Проверке подлежал полный корпус: 70 страниц объёмом около 550 тысяч знаков, охватывающих сводки, терминологию, 17 академических разборов, 12 компонентных спецификаций, 5 технических спецификаций с контрактами API, раздел SaaS-платформы, 13 аудитов конкурентов и план реализации. Задача аудита сформулирована владельцем корпуса как поиск неточностей и несоответствий между документами; фокус — внутренняя согласованность цифр, терминов, утверждений и перекрёстных ссылок.
Итог: обнаружено 43 находки — 4 критические, 23 средние и 16 низких. Корпус демонстрирует высокую связность на уровне стратегии: семь разрывов рынка трассируются в аудиты конкурентов, глоссарий согласован с терминологическими разборами, экономические расчёты франчайзинга сходятся между документами, а битых внутренних ссылок не найдено вовсе. Однако на уровне инженерных контрактов корпус рассинхронизирован: компоненты, модель данных и технические спецификации описывают три несовместимых словаря статусов заказа, два имени ключевого поля источника заказа и два момента списания по техкартам. Для документации, по которой предполагается писать код, это критический уровень риска.
К числу самых значимых находок относятся также: инверсия смысла требования 152-ФЗ об уведомлении об утечке в академическом разборе (документ буквально предписывает «не уведомлять» регулятора), комиссия агрегаторов, приводимая в четырёх неоговорённых представлениях, четыре разных срока онбординга точки (от «за часы» до «≤ 3 рабочих дней»), устаревший аудит-отчёт, описывающий корпус из 30 документов вместо 70, и расхождение заявленных чисел демо (30 экранов и 66 сценариев) с собственной таблицей покрытия (34 и 77).
Таблица 1. Ключевые показатели аудита
| Показатель | Значение |
|---|---|
| Проверено страниц | 70 (68 в sitemap + 2 обнаруженных сверх карты) |
| Объём корпуса | ~550 тыс. знаков, ~78 тыс. слов |
| Всего находок | 43: критических — 4, средних — 23, низких — 16 |
| Битые внутренние ссылки | 0 (все относительные ссылки разрешаются) |
| Страниц вне sitemap.xml | 2 (в т.ч. полноценная страница saas/03) |
| Страниц со статусом/датой ревизии | 0 из 70 |
| Тематических групп противоречий | 6 (данные, деньги, обещания, регуляторика, демо, терминология) |
Отчёт построен следующим образом: раздел 3 детально разбирает критические несоответствия, раздел 4 группирует междокументные противоречия по шести темам, раздел 5 фиксирует фактические ошибки академических разборов, разделы 6–7 отделяют формальные проблемы от того, что проверено и подтверждено, раздел 8 предлагает волновой план исправлений. Полный реестр всех 43 находок с цитатами и рекомендациями передан в виде книги Excel (lovii_crm_audit_register.xlsx) и служит рабочим чек-листом доработки корпуса.
2. Объект, объём и методика аудита¶
Объектом аудита является документационный корпус проекта lovii — ресторанной платформы полного цикла «заказ → чек → кухня → списание → курьер → отзыв → франшиза». Корпус опубликован как статический сайт на MkDocs Material и включает одиннадцать разделов: сводки и аудит корпуса (3 страницы), терминологические разборы (4), академическую серию (17), рынок и архитектуру (4), компоненты (12), технические спецификации (5), платёжную инфраструктуру (1), SaaS-платформу и демо (4), аудиты аналогов (13), выводы и планы (5), а также каталог схем и интерактивное демо. Аудит ограничен внутренней согласованностью: внешние источники (Росстат, НКР, публикации вендоров) перепроверялись выборочно — только там, где находка порождала внутреннее противоречие.
Методика состояла из пяти шагов. Первый — полный обход сайта по sitemap.xml с загрузкой всех 68 страниц и извлечением чистого текста; в ходе структурной проверки были обнаружены две дополнительные страницы вне карты сайта (интерактивное демо и страница сценариев ролей), после чего корпус составил 70 страниц. Второй шаг — автоматические проверки: разрешение 1 200+ внутренних ссылок с учётом относительных путей, поиск битых якорей, инвентаризация статус-меток и дат. Третий шаг — чтение ядра корпуса (сводки, рынок, blueprint, планы, спецификации) с фиксацией «канонической базы фактов». Четвёртый шаг — параллельная обработка всех остальных разделов по четырём направлениям (компоненты, академическая серия, конкуренты и инфраструктура, терминология и схемы) с построением факт-листов: каждое числовое утверждение, определение термина и перекрёстная ссылка заносились в реестр. Пятый шаг — сквозная сверка факт-листов с канонической базой и между собой, после чего каждая гипотеза о противоречии верифицировалась вручную по исходному тексту страницы.
Каждая находка получила идентификатор (F-01…F-43), серьёзность, тип, привязку к файлам, короткую цитату-доказательство и рекомендацию. Серьёзность присваивалась по влиянию: «критично» — противоречие блокирует разработку или искажает юридический смысл; «средне» — противоречие дезориентирует читателя, инвестора или команду; «низко» — формальные дефекты, опечатки и гигиена источников. Выборочные утверждения, опровергающие первоисточники (число пунктов DINESERV, даты Правила ФТК), дополнительно сверялись с внешними публикациями.
3. Критические несоответствия¶
Критическими признаны четыре находки: три касаются модели данных и жизненного цикла заказа — фундамента, на котором собирается вся платформа, — и одна искажает юридическое требование к обработке персональных данных. Во всех четырёх случаях расхождение подтверждено цитатами из нескольких документов корпуса, а не единичным ляпом: это следствие параллельной доработки разделов без единого источника правды.
3.1. Три несовместимых словаря статусов заказа и кухни (F-01)¶
Компонент 03 «Кухня и KDS» объявляет: «Статусы accepted, kitchen, cooking, ready, served, packed, courier — единый словарь для зала и доставки». Но спецификация 01 описывает жизненный цикл заказа в виде другой машины состояний — new → accepted → kitchen → ready → served/packed → delivered|cancelled, — где статуса cooking нет вовсе, зато появляются new, delivered и cancelled. Контракт данных components/12, по которому предполагается проектировать БД, фиксирует третий вариант: KitchenTicket = queued | cooking | ready | served без accepted, kitchen и packed. Референс-архитектура добавляет четвёртый: queued → cooking → ready → expo/served, packed, — причём статус expo из её же формулы отсутствует даже в модели данных.
Практическое следствие: две команды, одна из которых читает компонент 03, а другая — спецификацию 01, реализуют разные жизненные циклы, и стыковка фронт-офиса с кухней потребует переделки. Токен courier в «едином словаре» компонента 03 одновременно смешивает уровень заказа с уровнем доставки, где статусами управляет отдельная сущность DeliveryAssignment. Корпус неоднократно декларирует принцип «единой модели данных на все каналы» — противоречие в самих статусах подрывает именно его.
Таблица 2. Словари статусов по документам
| Документ | Статусы заказа/кухни | Чего не хватает |
|---|---|---|
| components/03 (KDS) | accepted, kitchen, cooking, ready, served, packed, courier | queued, new, delivered, cancelled |
| specs/01 (машина состояний) | new → accepted → kitchen → ready → served/packed → delivered | cancelled | cooking, queued, expo |
| components/12 (модель данных) | queued | cooking | ready | served | accepted, kitchen, packed, expo, delivered |
| 01-reference-architecture | queued → cooking → ready → expo/served, packed | accepted, kitchen, delivered |
| components/05 (доставка) | accepted → cooking → packed → assigned → picked_up → delivering → delivered → paid → review | каких-либо статусов кухни |
Рекомендация: зафиксировать один канонический перечислимый тип в components/12 и specs/01 (включая expo, packed, delivered, cancelled и явный статус оплаты), а компоненты 03 и 05 перевести на ссылки к нему. Изменение занимает часы, но снимает главный инженерный риск корпуса.
3.2. Доставка: picked против picked_up и две модели отказа (F-02)¶
На уровне доставки расхождение повторяется в меньшем масштабе, но с тем же эффектом. Модель данных (components/12) и спецификация 01 используют статус забора picked и статус отказа failed; компонент 05 — picked_up и отдельную сущность инцидента с переходом incident → cancelled. Различаются и поля подтверждения: компонент 05 обещает «фото или код» вручения, тогда как модель допускает только proof_photo. Контракт API specs/03 в этой части молчит, хотя именно статусы курьера питают обещания времени и уведомления гостя.
Для диспетчеризации это не косметика: обработка инцидентов — «курьер не забрал», «заказ потерян», «гость не принял» — меняет логику возвратов и списаний. Рекомендация: выбрать один токен (picked_up читаемее и самоописываем), принять одну модель отказа и добавить поле кода вручения, если сценарий «фото или код» остаётся в обещаниях продукта.
3.3. Поле источника заказа: source против channel (F-03)¶
Компонент 02 и референс-архитектура описывают заказ с полем source («Канал создаёт заказ: Order(source, items, guest_id)»), тогда как модель данных, доменная модель и контракт API используют поле channel с перечислением pos | site | app | miniapp | kiosk | aggregator:yandex. Имя ключевого поля «единой модели данных» — главного архитектурного принципа корпуса — не согласовано между пятью документами. Дополнительная шероховатость: канал «телефон/колл-центр» упомянут в компоненте 02 как полноценный канал приёма, но отсутствует в обоих перечислениях.
Рекомендация: закрепить channel (как в контракте API — он однозначнее для аналитики каналов), дополнить перечисление каналом колл-центра и синхронизировать референс-архитектуру с моделью. До этого любые схемы аналитики «выручка по каналам» будут расходиться с фактической схемой БД.
3.4. Инверсия требования 152-ФЗ об уведомлении об утечке (F-04)¶
Академический разбор 4 «Лояльность и ПДн» в разделе требований к платформе утверждает: «обязателен сам факт неуведомления об утечке в Роскомнадзор». Требование прочитано наоборот: по ст. 21 152-ФЗ оператор обязан уведомить Роскомнадзор об инциденте с персональными данными в течение 24 часов, а с 30 мая 2025 года за неуведомление введены значительные административные штрафы. Ошибка находится в документе, который в навигации корпуса назван «режим 152-ФЗ, сравнение с GDPR, чек-лист платформы», — то есть позиционируется как регуляторный ориентир для продукта.
Соседние утверждения того же раздела также требуют верификации: штраф «обработка без законного основания — до 300 тыс ₽» приведён без источника и может смешиваться со штрафом за неуведомление. Рекомендация: исправить формулировку на уведомление в течение 24 часов, заменить источники-заглушки ссылками на первоисточники (152-ФЗ, КоАП ст. 13.11) и включить регуляторные суммы в юридическую проверку. В документа, продающего «комплаенс из коробки», инверсия требования — репутационный риск.
4. Противоречия между документами по темам¶
Двадцать три средних находки группируются в шесть тем: деньги и тарифы, обещания продукта, регуляторика, контракты данных, демо и роли, терминология и арифметика. Ниже по каждой теме приведён разбор ключевого конфликта и сводная таблица остальных расхождений темы. Полные цитаты — в Excel-реестре.
4.1. Деньги: комиссии, тарифы и ценовой пол (F-05, F-10, F-15, F-16, F-17, F-25, F-26)¶
Самая широкая тема. Комиссии агрегаторов приводятся в четырёх представлениях: 17–30% в резюме, обзоре рынка и компоненте доставки; 16,67–29,17% без НДС в картах систем, компоненте каналов и юнит-экономике; 20–30% в третьем разделе того же юнит-экономического разбора; 20–35% как «экономия на прямых заказах» в опорном стеке и аудите middleware. Арифметически первая, вторая и четвёртая согласуются (16,67–29,17% × 1,2 НДС = 20–35%), но эквивалентность нигде не оговорена — читатель видит четыре разные цифры. Аналогично тарифная вилка «тяжёлых» систем «8–10+ тыс ₽/мес за кассу» опровергается собственными файлами: r_keeper Cloud оценён «от 4 085 ₽/мес», 1С:Фреш — «~2 684 ₽/мес», из-за чего ломается и утверждённая в обзоре рынка вилка «дешевле в 3–5 раз» (Quick Resto 4 990 ₽ против r_keeper Cloud 4 085 ₽ — разница 1,2×).
Таблица 3. Расхождения по теме «деньги»
| ID | Где | Суть расхождения |
|---|---|---|
| F-05 | exec/market vs plan/02 vs academic/02 | Комиссия агрегаторов: 17–30% ↔ 16,67–29,17% без НДС ↔ 20–30% ↔ 20–35%; база (НДС) не указана |
| F-10 | exec/G3 vs rkeeper/1c файлы | «Тяжёлые 8–10+ тыс ₽/мес» ↔ r_keeper Cloud от 4 085 ₽, 1С:Фреш ~2 684 ₽/мес; «дешевле в 3–5 раз» не сходится |
| F-15 | infrastructure внутренне + plan/02 | СБП 0,4–0,7% ↔ 0,3–0,7%; ККТ 12–60 тыс ↔ 20–60 тыс; ФН 8,5–15 ↔ 10–15 тыс; обл. касса 1,5–3,9 ↔ 1,5–3 тыс |
| F-16 | saby-presto vs ru-smaller/toast/square | «Ценовой пол рынка ~2 000 ₽/мес» ↔ модели 0 ₽ (Fusion POS, Toast $0, Square Free) |
| F-17 | audit-report vs touchbistro | «TouchBistro цену не раскрывает» ↔ «от $69/мес за терминал» в файле конкурента |
| F-25 | exec vs index | «14 классов систем» ↔ 13 файлов конкурентов ↔ 11 карточек навигации |
| F-26 | components/02 vs middleware | Otter: «100+ интеграций» ↔ «POS-интеграции с 20+ кассовыми системами» |
Рекомендация по теме: зафиксировать в market-landscape канонические вилки с указанием базы («с НДС/без НДС», «за кассу/за точку»), остальные документы перевести на ссылки; переформулировать тарифное обобщение как «флагманские тарифы iiko Pro 8 600–10 600 ₽/мес» и ввести определение «класса системы», чтобы числа перестали расходиться.
4.2. Обещания продукта: онбординг, API, роялти, списание (F-06, F-07, F-14, F-21, F-22)¶
Срок онбординга точки варьируется от «за часы» (компонент франшизы, академический разбор 11, сценарий персоны U6) через «за день» (разрыв G7) до «≤ 3 дней» и «≤ 3 рабочих дней» (метрика blueprint и гейт фазы 4). Это не словесность: обещание попадает в инвест-материалы и в KPI продукта. Похожая судьба у принципа «открытый API с первого дня»: референс-архитектура заявляет его, компонент 11 включает чекбокс API в DoD MVP, но blueprint относит открытый API к P2/фазе 5, а план первых 90 дней его не упоминает. Третий конфликт — момент списания по ТТК: последовательность в specs/02 списывает ингредиенты при пробитии чека, тогда как компонент 03 прямо требует списания по статусу «готов», и демо работает именно так; при пробитии на отменах будет списываться незакупленное сырье.
Таблица 4. Расхождения по теме «обещания»
| ID | Где | Суть расхождения |
|---|---|---|
| F-06 | G7 vs comp/09 vs blueprint vs plan/01 | Онбординг: «за день» ↔ «за часы» ↔ «≤3 дня» ↔ «≤3 рабочих дней» |
| F-07 | ref-arch/comp-11 vs blueprint/plan | «Открытый API с первого дня» и в DoD MVP ↔ P2/фаза 5, отсутствует в MVP-плане |
| F-14 | specs/02 vs comp/03 и демо | Списание по ТТК при пробитии ↔ при статусе «готов» |
| F-21 | terminology vs comp/09 | Франшиза — «надстройка над классами» ↔ «не надстройка, а способ существования продукта» |
| F-22 | personas П4/П5 vs terminology | Роялти «еженедельно» ↔ «в конце месяца» ↔ ежемесячно; период не зафиксирован в comp/09 |
Рекомендация: развести два показателя онбординга («шаблон клонируется за часы» — технический факт гейта Ф0; «полный запуск ≤ 3 рабочих дней» — продуктовая метрика) и использовать только их; переформулировать API как «внутренний контракт с фазы 1, публичный маркетплейс — фаза 5»; закрепить списание по готовности в specs/02; зафиксировать расчётный период роялти (например, понедельный расчёт с месячным закрытием).
4.3. Регуляторика: даты ФФД 1.2 (F-08, F-43)¶
Сроки обязательности ФФД 1.2 сформулированы тремя способами: «обязателен с 01.02–01.03.2025/2026» (обзор рынка — запись, не читаемая однозначно), «с 01.02.2025 для новых регистраций; с 01.03.2026 — единственный формат» (компонент 01), «формат 1.05 выведен с 01.03.2026» (инфраструктура). Глоссарий при этом сужает требование до «обязательная версия для маркировки», хотя компоненты 01 и 10 описывают всеобщую обязательность для новых ККТ. Для продукта, продающего «кассу из коробки», регуляторные даты — ядро ценностного предложения, и их разнобой в маркетинговых материалах опаснее любых технических опечаток.
Рекомендация: одна каноническая формулировка с двумя датами (новые регистрации с 01.02.2025; все новые ККТ с 01.03.2026) живёт в глоссарии; обзор рынка ссылается на неё; компонент 01 остаётся техническим источником. Заодно дополнить определение ФФД так, чтобы у читателя не возникло решения «у нас нет маркировки — ФФД 1.2 не нужен».
4.4. Контракты данных: заказ, склад, франшиза (F-09, F-24, F-32)¶
Контракт создания заказа расходится между моделью данных и API-спецификацией: components/12 описывает guest_phone?, payment_intent и перечисление каналов с phone; specs/03 — вложенный объект guest с полем consent, idempotency_key и delivery.slot, которого в модели нет. Поскольку именно эти два документа читают разработчики, расхождение эквивалентно двум разным ТЗ. Далее: сущность FranchiseAccount, названная в референс-архитектуре «ключевой», в модели данных отсутствует (её роль частично исполняют FranchiseAgreement и RoyaltyInvoice); в спецификации 01 у StockMovement восемь типов движений, в модели — девять (потерян writeoff_staff, важный для антифрода); подтверждение вручения в модели не имеет поля кода.
Рекомендация: объявить specs/03 источником контракта, components/12 — источником модели, и синхронизировать пары «поле ↔ атрибут» одним проходом; решить судьбу FranchiseAccount (ввести или пометить замещение); добавить writeoff_staff в specs/01 и proof_code в модель доставки.
4.5. Демо и роли: числа и состав (F-12, F-13, F-33, F-36)¶
Индекс и спецификация демо-кабинета повторяют «30 экранов, 10 ролей, 66 интерактивных сценариев», но сводная таблица раздела 13 страницы сценариев суммируется в 34 экрана и 77 действий. В таблице ролей демо-кабинета девять строк при выводе «Итого 10 ролей» — десятая роль, Закупщик, потеряна и в диаграмме людей карты платформы, хотя полноценный раздел сценариев Закупщика существует. Ролевые наборы по корпусу вообще не совпадают: 11 ролей в референс-архитектуре, 10 в демо, 8 в компоненте персонала, 7 в контексте спецификации 00, а названия плавают («Владелец»/«Собственник», «Менеджер УК»/«Операционный директор УК»). Контур франчайзи в сценариях — только crm, в демо и карте — crm + erp.
Рекомендация: пересчитать фактические маршруты демо и привести три документа к одним числам (добавив строку «Итого» в таблицу покрытия); вернуть Закупщика в таблицу ролей и диаграмму людей; завести единый реестр ролей с каноническими именами в глоссарии.
4.6. Арифметика и база процентов (F-19, F-20, F-27)¶
В академических разборах и компонентах есть три нестыковки, бьющие по доверию к цифрам. Правило «30/30/30/10» цитируется в расшифровке «аренда+ЖКХ / ФОТ / фудкост / прибыль», при этом собственная таблица бенчмарков того же разбора даёт аренду 10–15% и ориентир фудкоста 25% — правило противоречит соседней таблице. Пример «1 п.п. фудкоста при рентабельности 8% = ±10% прибыли» арифметически неверен: 50 тыс ₽ от прибыли 400 тыс ₽ — это 12,5%. Введение компонента кухни «теряются или зарабатываются 25–35% себестоимости» сбивает базу: в остальном корпусе 25–35% — диапазон ФОТ от выручки, а фудкост считается от выручки.
Рекомендация: привести каноническую расшифровку правила структуры затрат или заменить его собственным целевым балансом; исправить пример на «±12,5% прибыли» (или сменить базовую рентабельность на 10%); переформулировать вступление компонента 03 через п.п. фудкоста.
5. Фактические неточности в академических разборах¶
Академическая серия — сильная сторона корпуса: модели, принципы и классификации в большинстве сверены и корректны (Роджерс, Мэйстер, Голдратт, Касавана–Смит, модели CLV-когорт). Вместе с тем серия уже используется как источник терминов для остальных документов, поэтому фактические ошибки в ней тиражируются. Ниже — проверяемые расхождения с первоисточниками; случай 152-ФЗ рассмотрен в разделе 3.4 как критический.
Таблица 5. Расхождения с первоисточниками
| Документ | Утверждение корпуса | Как по первоисточнику |
|---|---|---|
| academic/08 | BG/BB — «Fader, Хардти, Ли (2007)», договорные (контрактные) отношения | BG/BB — Fader, Hardie, Shang (2010), неконтрактные дискретные транзакции; контрактный аналог — sBG (Fader & Hardie, 2007) (F-18) |
| academic/03 | DINESERV — «28 утверждений» | 29 пунктов (Stevens, Knutson & Patton, 1995; Cornell HRA Quarterly) (F-28) |
| academic/17 | Правило ФТК о франшизе — «1979, обновлено 2010» | Поправки приняты в 2007 (16 CFR Part 436), обязательны с 01.07.2008 (F-30) |
| academic/17 | «Конкурсное право ЕС касается вертикальных соглашений» | Вертикальные соглашения регулирует конкурентное (антимонопольное) право; конкурсное право — банкротство (F-29) |
| academic/06 | «Критическая контрольная точка (ККТ/CCp)» | Акроним ККТ в корпусе занят «контрольно-кассовой техникой»; для CCP устоялось КТК/«критическая точка контроля» (F-31) |
| terminology-franchise | Обязательность товарного знака — «с введением части четвёртой ГК» | Глава 54 ГК — в части второй (ст. 1027–1040); изменение режима товарных знаков — ФЗ-160 от 18.07.2008 (F-42) |
Отдельного внимания требуют источники: в разборах 1, 2 и 4 встречаются висячие сноски и названия-заглушки без ссылок, а во всех тринадцати файлах конкурентов числовые факт-маркеры не сопровождаются списком источников (он есть только у файла платёжной инфраструктуры). Для серии, которая претендует на академическую строгость и служит терминологическим ядром корпуса, закрытие сносок — недорогая работа с высоким эффектом.
6. Структурные и формальные проблемы¶
Структурные находки не искажают смысл отдельных утверждений, но снижают управляемость корпуса и его представимость для внешних читателей. Четыре группы проблем заслуживают внимания в первую очередь.
- Карта сайта неполна (F-38). sitemap.xml содержит 68 URL, но не содержит страницу сценариев ролей (полноценные 13 тыс. знаков контента, связанная из каталога схем) и интерактивное демо. Демо — JS-приложение, которое для поисковых систем и скринридеров выглядит пустой страницей; стоит добавить статическую заглушку с описанием.
- Нет метаданных ревизии (F-39). Ни одна из 70 страниц не имеет шапки со статусом и датой; даты встречаются лишь в трёх файлах. Прямое следствие — устаревший аудит-отчёт, который продолжает утверждать «30 документов» и «полнота 10/10» на корпус, выросший более чем вдвое (F-11).
- Ограничение аудита-отчёта расходится с фактом (F-17). Заявление «TouchBistro цену не раскрывает» опровергается файлом конкурента с ценой «от $69/мес» — раздел «ограничения» методологии теряет достоверность.
- Опечатки и бренд (F-40). «Отзыв госта», «покуток», «правилно», «горяней», «ФАТ/ВОЗ» вместо ФАО; бренд пишется lovii / «ловии» / «Ловии» в разных документах. Рекомендуется массовая вычитка и закрепление написания бренда.
Отдельного внимания заслуживают обещания без контракта. Спецификация 04 обещает «торговать без интернета неограниченно долго», тогда как blueprint задаёт проверяемую метрику «8 часов продаж без облака» (F-34); правило мок-банка «сумма кратна 997 → код 51» из демо-сценариев не описано в контракте мок-сервисов инфраструктуры, на который сценарий ссылается (F-37). В обоих случаях формулировка либо нереализуема в текущих документах, либо не подтверждена спецификацией, на которую указывает.
7. Проверено и подтверждено¶
Существенная часть корпуса сверку прошла безупречно — это важно зафиксировать, чтобы план исправлений не затирал работающее. Ниже перечислены сквозные согласованности, подтверждённые в ходе аудита с цитатами по каждой проверке (полный список — в листе «Позитивные проверки» Excel-реестра).
- Глоссарий и терминология. Определения фудкоста, ТТК, роялти, паушального взноса, франчайзера/УК согласованы между глоссарием и терминологическими разборами; термин «House Display System» не встречается, «КТТ» не встречается — везде ТТК.
- Экономика франчайзинга. Роялти 2–6% сходится в разборах 2, 5 и terminology-franchise; роялти «от фискальной выручки» согласовано по всему корпусу (ref-arch, specs, blueprint, демо).
- Трассируемость разрывов. Все 7 разрывов G1–G7 из gap-analysis подтверждаются цитатами из файлов конкурентов; «экономия 20–35%» подтверждена текстом middleware-delivery.
- Каталог схем. 58 диаграмм = 35+11+6+4+1+1 подтверждены полной инвентаризацией корпуса; «32 страницы» сходится; ~20 проверенных якорей существуют.
- Контракты API. specs/03 каноничен: 12 REST-ресурсов, ошибки 409/422/423, идемпотентность, каталог событий — без внутренних противоречий.
- Информационные потоки. saas/01: «семь правил движения информации» — ровно семь; схема «источники → журнал → контуры» согласована с картой app/crm/erp.
- Ссылки. Битых внутренних ссылок нет: все относительные ссылки корпуса разрешаются на существующие страницы (проверено обходом 70 страниц).
- Арифметика примеров. Расчёт инфраструктуры (18 000+1 400+500 ≈ 21 000 ₽ = 1,4% выручки) и пересчёт 1С:Фреш (32 200/12 ≈ 2 684 ₽/мес) сходятся.
- Согласованность демо. 10 ролей, дата сборки 10.10.2026, бонусы до 30% чека, авторизация мок-банка 0,7 с, индекс стандарта ≥85% — согласованы между saas/02, saas/03 и демо-данными.
- Право франчайзинга. 64% франчайзеров, ~7,8 тыс. договоров концессии, 14 дней + 23 пункта FDD — согласованы между academic/17 и terminology-franchise.
Из позитивных сверок следует практический вывод: стратегический слой корпуса (разрывы, экономика франшизы, глоссарий, каталожная механика) можно переиспользовать как есть, сосредоточив усилия на инженерных контрактах и числовых вилках. Это повышает приоритет волны 1 плана исправлений из раздела 8.
8. Приоритетный план исправлений¶
План разбит на три волны по принципу «сначала то, что блокирует разработку и юридически опасно, затем то, что видно читателю и инвестору, затем гигиена». Каждая строка привязана к находкам реестра и оценена по усилию: S — до половины дня, M — до двух дней, L — до недели работы одним владельцем.
Таблица 6. Волна 1 — блокеры разработки и юридические риски
| Действие | Находки | Владелец | Усилие |
|---|---|---|---|
| Зафиксировать единый словарь статусов заказа/кухни/доставки в comp-12 и specs/01, остальные документы — на ссылки | F-01, F-02, F-32 | Архитектор | M |
| Синхронизировать контракт заказа (channel, guest/consent, slot, idempotency) между comp-12 и specs/03 | F-03, F-09 | Техлид API | S |
| Исправить инверсию 152-ФЗ и заменить источники-заглушки; юрверификация штрафов | F-04, F-41 | Юрист + автор | S |
| Зафиксировать канонические вилки комиссий и тарифов с указанием базы НДС; переформулировать «тяжёлые 8–10+ тыс» | F-05, F-10 | Аналитик | S |
| Провести ревизию №2 аудита-отчёта (документы, ссылки, ограничения, TouchBistro) | F-11, F-17 | Владелец корпуса | M |
Таблица 7. Волна 2 — публичные обещания и числа
| Действие | Находки | Владелец | Усилие |
|---|---|---|---|
| Развести «клонирование шаблона за часы» и «запуск точки ≤3 раб. дней» по всем документам | F-06 | Продакт | S |
| Единая формулировка сроков ФФД 1.2 в глоссарии; поправить обзор рынка | F-08, F-43 | Автор comp-01 | S |
| Пересчитать маршруты демо; привести 30/66 к фактам; вернуть Закупщика в роли | F-12, F-13 | Автор демо | S |
| Списание по ТТК — по готовности; поправить specs/02; период роялти зафиксировать | F-14, F-22 | Архитектор | S |
| Каноническая расшифровка 30/30/30/10; исправить ±10% → ±12,5%; база «25–35%» | F-19, F-20, F-27 | Автор разборов | S |
| Атрибуция BG/BB, DINESERV 29, ФТК 2007, «конкурентное право», ККТ-коллизия | F-18, F-28…F-31, F-42 | Автор разборов | S |
Таблица 8. Волна 3 — гигиена корпуса
| Действие | Находки | Владелец | Усилие |
|---|---|---|---|
| Метаданные «статус/дата ревизии» в шапку каждой страницы; переопубликовать sitemap; заглушка для /demo/ | F-38, F-39 | DevOps | M |
| Секции «Источники» в 13 файлах конкурентов; закрыть висячие сноски разборов 1/2/4 | F-39, F-41 | Автор | L |
| Единый реестр ролей и названий контуров в глоссарии; прогон замены по корпусу | F-23, F-33, F-36 | Редактор | M |
| Вычитка опечаток; закрепить написание бренда «lovii» | F-40 | Редактор | S |
| Ценовой пол, Otter, Poster (валюты и лимиты), «14 классов», FranchiseAccount, offline 8 часов | F-16, F-24, F-25, F-26, F-34, F-35, F-37 | Аналитик | M |
Ожидаемый эффект волны 1: корпус становится безопасным источником для команд разработки; волны 2 — формулировки продукта и цифры перестают расходиться в презентациях; волны 3 — корпус получает управляемость (метаданные, источники, единая терминология), и следующая ревизия будет стоить заметно дешевле.
9. Приложение: статистика корпуса и сводка реестра¶
Ниже приведена статистика проверенного корпуса и сводка находок по разделам и серьёзности. Полный реестр с цитатами, привязкой к файлам и рекомендациями передан в книге Excel lovii_crm_audit_register.xlsx (лист «Реестр находок», 43 строки; листы «Сводка», «Позитивные проверки», «Методика»).
Таблица 9. Состав корпуса
| Раздел | Документы | Страниц |
|---|---|---|
| Сводки и аудит корпуса | index, executive-summary, audit-report | 3 |
| Терминология и сравнения | crm-vs-erp, terminology-crm-erp, terminology-franchise, academic-research-agenda | 4 |
| Академические разборы | academic/01…17 | 17 |
| Рынок и архитектура | 00-market-landscape, 01-reference-architecture, 02-personas-cjm, glossary | 4 |
| Компоненты | components/01…12 | 12 |
| Технические спецификации | specs/00…04 | 5 |
| Платёжная инфраструктура | infrastructure/banks-kassa-ofd | 1 |
| SaaS-платформа и демо | saas/00…03 | 4 |
| Аудиты аналогов | competitors/* | 13 |
| Выводы и планы | gap-analysis, product-blueprint, plan/01…03 | 5 |
| Каталог схем + демо-приложение | diagram-catalog, /demo/ (JS-приложение) | 2 |
Таблица 10. Находки по разделам и серьёзности
| Раздел | Критично | Средне | Низко | Всего |
|---|---|---|---|---|
| Компоненты | 3 | 3 | 0 | 6 |
| Академические разборы | 1 | 3 | 5 | 9 |
| Резюме | 0 | 3 | 0 | 3 |
| Gap-анализ | 0 | 1 | 0 | 1 |
| Референс-архитектура | 0 | 2 | 0 | 2 |
| Рынок | 0 | 1 | 0 | 1 |
| Аудит-отчёт | 0 | 2 | 0 | 2 |
| Индекс | 0 | 1 | 0 | 1 |
| SaaS | 0 | 2 | 2 | 4 |
| Спецификации | 0 | 1 | 2 | 3 |
| Платёжная инфраструктура | 0 | 1 | 0 | 1 |
| Конкуренты | 0 | 1 | 1 | 2 |
| Терминология | 0 | 1 | 1 | 2 |
| Персоны | 0 | 1 | 0 | 1 |
| Архитектура | 0 | 0 | 1 | 1 |
| Структура сайта | 0 | 0 | 1 | 1 |
| Весь корпус | 0 | 0 | 1 | 1 |
| Несколько разделов | 0 | 0 | 1 | 1 |
| Глоссарий | 0 | 0 | 1 | 1 |
| Итого | 4 | 23 | 16 | 43 |
Ограничения аудита: проверялась внутренняя согласованность корпуса; внешние первоисточники сверялись выборочно (DINESERV, даты ФТК, положения 152-ФЗ), поэтому отдельные числовые утверждения рынка (оборот, число заведений, цены вендоров на момент публикации) не перепроверялись и требуют отдельной сверки перед инвест-материалами. Живое тестирование демо и конкурентов не входило в объём — корпус сам фиксирует это как следующий шаг; выводы аудита следует пересматривать после ревизии №2 корпуса и получения демо-доступов.