Аудит документации платформы lovii — реестр находок

Аудит корпуса документации lovii-crm: «Super Z Audit», ревизия №1, 10 октября 2026 года. 70 страниц.

Сводка

Показатель	Значение
Объект аудита	bestdeejay-design.github.io/lovii-crm (MkDocs Material, GitHub Pages)
Дата аудита	2026-10-10
Проверено страниц	70
Объём корпуса	~550 тыс. знаков
Всего находок	43
Критичных	4
Средних	23
Низких	16
Битые внутренние ссылки	0 (все относительные ссылки разрешаются)
Страниц вне sitemap.xml	2: /demo/ и /research/saas/03-role-scenarios/
Страниц со статусом/датой ревизии	0 из 70
Файл подробного отчёта	lovii_crm_audit_report.docx (18 стр.)

Счётчики находок считаются формулами от листа «Реестр находок» и обновляются автоматически.

Реестр находок

Обзор находок

ID	Серьёзность	Тип	Файлы
F-01	КРИТИЧНО	Противоречие между документами	components/03-kitchen-kds · components/05-delivery-couriers …
F-02	КРИТИЧНО	Противоречие между документами	specs/01-domain-model · components/12-data-model …
F-03	КРИТИЧНО	Противоречие между документами	components/02-order-channels · 01-reference-architecture …
F-04	КРИТИЧНО	Фактическая ошибка	academic/04-personal-data-loyalty
F-05	СРЕДНЕ	Противоречие между документами	executive-summary · 00-market-landscape …
F-06	СРЕДНЕ	Противоречие между документами	gap-analysis · components/09 …
F-07	СРЕДНЕ	Противоречие между документами	01-reference-architecture · components/11-integration-platform …
F-08	СРЕДНЕ	Противоречие между документами	00-market-landscape · components/01-pos-fiscal …
F-09	СРЕДНЕ	Противоречие между документами	components/12-data-model · specs/03-api-contracts
F-10	СРЕДНЕ	Противоречие между документами	executive-summary · gap-analysis …
F-11	СРЕДНЕ	Пробел/устаревание	research/audit-report
F-12	СРЕДНЕ	Противоречие между документами	index · saas/02-demo-cabinet …
F-13	СРЕДНЕ	Противоречие между документами	saas/02-demo-cabinet · saas/00-platform-map …
F-14	СРЕДНЕ	Противоречие между документами	specs/02-processes · components/03-kitchen-kds …
F-15	СРЕДНЕ	Внутреннее противоречие	infrastructure/banks-kassa-ofd · plan/02-systems-roadmap
F-16	СРЕДНЕ	Противоречие между документами	competitors/saby-presto · competitors/ru-smaller …
F-17	СРЕДНЕ	Противоречие между документами	research/audit-report · competitors/square-touchbistro-revel
F-18	СРЕДНЕ	Фактическая ошибка	academic/08-clv-models
F-19	СРЕДНЕ	Внутреннее противоречие	academic/01-management-accounting · academic/02-unit-economics
F-20	СРЕДНЕ	Арифметическая ошибка	academic/02-unit-economics
F-21	СРЕДНЕ	Противоречие между документами	terminology-crm-erp · components/09-franchise-network
F-22	СРЕДНЕ	Противоречие между документами	02-personas-cjm · terminology-franchise
F-23	СРЕДНЕ	Терминология	saas/00-platform-map · terminology-crm-erp …
F-24	СРЕДНЕ	Пробел/устаревание	01-reference-architecture · components/12-data-model …
F-25	СРЕДНЕ	Счётность	executive-summary · index …
F-26	СРЕДНЕ	Противоречие между документами	components/02-order-channels · competitors/middleware-delivery
F-27	СРЕДНЕ	Сбита база процента	components/03-kitchen-kds · components/07-hr-staff …
F-28	НИЗКО	Фактическая ошибка	academic/03-service-quality
F-29	НИЗКО	Терминология	academic/17-franchise-law-comparative
F-30	НИЗКО	Фактическая ошибка	academic/17-franchise-law-comparative
F-31	НИЗКО	Коллизия акронима	academic/06-food-safety-terminology · glossary
F-32	НИЗКО	Расхождение	specs/01-domain-model · components/12-data-model …
F-33	НИЗКО	Дрейф имён	01-reference-architecture · components/07 …
F-34	НИЗКО	Противоречие между документами	specs/04-deployment-offline · product-blueprint
F-35	НИЗКО	Неточность	competitors/poster · gap-analysis
F-36	НИЗКО	Расхождение	saas/00-platform-map · saas/03-role-scenarios
F-37	НИЗКО	Пробел	saas/03-role-scenarios · infrastructure/banks-kassa-ofd
F-38	НИЗКО	Структура	sitemap.xml · /demo/ …
F-39	НИЗКО	Пробел	68 страниц корпуса · 13 файлов конкурентов
F-40	НИЗКО	Стиль/опечатки	crm-vs-erp · academic/08 …
F-41	НИЗКО	Источники	academic/04-personal-data-loyalty
F-42	НИЗКО	Неточность	terminology-franchise · academic/17
F-43	НИЗКО	Формулировка	glossary · components/01 …

Критичные (4)

F-01 — КРИТИЧНО · Противоречие между документами

• Раздел корпуса: Компоненты, спецификации, архитектура
• Файлы: components/03-kitchen-kds · components/05-delivery-couriers · components/12-data-model · specs/01-domain-model · 01-reference-architecture
• Суть находки: Три несовместимых словаря статусов заказа и кухни при заявленном «едином словаре». Компонент 03 объявляет «единый словарь» accepted → kitchen → cooking → ready → served → packed → courier. Спецификация 01 описывает другую машину состояний: new → accepted → kitchen → ready → served/packed → delivered|cancelled (статусы cooking нет, зато есть new, delivered, cancelled). Компонент 12 — контракт данных для разработки — фиксирует третий вариант: KitchenTicket = queued|cooking|ready|served (без accepted, kitchen, packed), а референс-архитектура четвёртый: queued → cooking → ready → expo/served, packed (статус expo отсутствует даже в модели данных).
• Цитата / доказательство: «Статусы accepted, kitchen, cooking, ready, served, packed, courier — единый словарь для зала и доставки» (components/03, §1.5)
• С чем расходится: specs/01: «new → accepted → kitchen → ready → served/packed → delivered | cancelled»; components/12: «status (queued | cooking | ready | served)»; ref-arch: «KDS: queued → cooking → ready → expo/served, packed»
• Рекомендация: Зафиксировать один канонический enum в components/12 и specs/01 (включая expo, packed, delivered, cancelled), остальные документы перевести на ссылки к нему. Это блокер для разработки: разные команды прочитают по-разному.

F-02 — КРИТИЧНО · Противоречие между документами

• Раздел корпуса: Компоненты, спецификации
• Файлы: specs/01-domain-model · components/12-data-model · components/05-delivery-couriers
• Суть находки: Доставка: два токена забора заказа и две модели отказа. В спецификации 01 и компоненте 12 статус забора — picked, отказ — failed. В компоненте 05 — picked_up, а инциденты моделируются отдельной сущностью с переходом incident → cancelled. Контракт API specs/03 не определяет ни один из вариантов, хотя именно через статусы курьера строятся обещания времени и уведомления гостя.
• Цитата / доказательство: components/12: «status (assigned | picked | delivering | delivered | failed)… proof_photo?»
• С чем расходится: components/05: «assigned --> picked_up: курьер забрал; picked_up --> delivering: в пути» + инцидент/cancelled
• Рекомендация: Выбрать один токен (picked_up читаемее) и одну модель отказа (отдельная сущность инцидента или статус failed), синхронизировать specs/01, components/12, specs/03.

F-03 — КРИТИЧНО · Противоречие между документами

• Раздел корпуса: Компоненты, спецификации, архитектура
• Файлы: components/02-order-channels · 01-reference-architecture · components/12-data-model · specs/01 · specs/03
• Суть находки: Поле источника заказа: source в одних документах, channel в других. Компонент 02 («каналы приёма заказов») и референс-архитектура описывают заказ с полем source (Order(source, items, guest_id)), тогда как контракт данных (components/12), доменная модель (specs/01) и контракт API (specs/03) используют channel с перечислением pos | site | app | miniapp | kiosk | aggregator:yandex. Для «единой модели данных на все каналы» — главного архитектурного принципа корпуса — имя ключевого поля не согласовано.
• Цитата / доказательство: 01-reference-architecture: «Канал создаёт заказ: Order(source, items, guest_id)»
• С чем расходится: specs/03: «"channel": "pos | site | app | miniapp | kiosk | aggregator:yandex"»
• Рекомендация: Закрепить channel (как в контракте API), добавить в перечисление канал «телефон/колл-центр», упомянутый в components/02.

F-04 — КРИТИЧНО · Фактическая ошибка

• Раздел корпуса: Академические разборы
• Файлы: academic/04-personal-data-loyalty
• Суть находки: Инверсия смысла требования 152-ФЗ об уведомлении об утечке. В разборе 4 утверждается, что «обязателен сам факт неуведомления об утечке в Роскомнадзор» — то есть документ фактически требует НЕ уведомлять. По ст. 21 152-ФЗ оператор обязан уведомить Роскомнадзор об инциденте в течение 24 часов (с 01.09.2022), а с 30.05.2025 действуют штрафы за неуведомление до 1 млн ₽ (КоАП 13.11). Требование прочитано наоборот — в документе, который позиционируется как чек-лист соответствия платформы.
• Цитата / доказательство: «обязателен сам факт неуведомления об утечке в Роскомнадзор» (academic/04, §3)
• С чем расходится: Ст. 21 152-ФЗ: уведомление об утечке — обязанность оператора в течение 24 ч; штрафы КоАП ст. 13.11 — именно за неуведомление
• Рекомендация: Исправить на «обязательно уведомление Роскомнадзора об утечке в течение 24 часов»; заодно перепроверить соседнюю цифру «обработка без законного основания — до 300 тыс ₽» (источник в тексте не указан).

Средние (23)

F-05 — СРЕДНЕ · Противоречие между документами

• Раздел корпуса: Резюме, рынок, компоненты, планы, академия
• Файлы: executive-summary · 00-market-landscape · components/05 · plan/02 · plan/03 · components/02 · academic/02
• Суть находки: Комиссии агрегаторов: одна величина в четырёх представлениях без оговорки об эквивалентности. Корпус оперирует четырьмя вариантами: 17–30% (executive-summary, market-landscape, components/05), 16,67–29,17% без НДС (plan/02, plan/03, components/02, academic/02 §4), 20–30% (academic/02 §3) и 20–35% — как «экономия на прямых заказах» (plan/03, competitors/middleware-delivery). Арифметически 16,67–29,17% × 1,2 (НДС) = ровно 20–35%, и «17–30%» — округление, но эквивалентность нигде не оговорена, а в middleware-delivery и infrastructure базовая ставка вообще не названа.
• Цитата / доказательство: executive-summary: «комиссия агрегаторов 17–30%» ↔ plan/02: «комиссии 16,67–29,17% без НДС»
• С чем расходится: academic/02 §3: «Комиссия агрегатора 20–30%» внутри того же файла, где §4 даёт 16,67–29,17%
• Рекомендация: Зафиксировать одну каноническую вилку с указанием базы (с НДС/без НДС) в market-landscape, остальные документы — на ссылку; добавить сноску «16,67–29,17% без НДС ≡ 20–35% с НДС».

F-06 — СРЕДНЕ · Противоречие между документами

• Раздел корпуса: Gap-анализ, компоненты, академия, персоны, blueprint, планы
• Файлы: gap-analysis · components/09 · academic/11 · 02-personas-cjm · product-blueprint · plan/01
• Суть находки: Срок онбординга точки: четыре формулировки одного обещания. Одно и то же обещание варьируется: «онбординг точки за день» (gap-анализ, разрыв G7), «точка готова к запуску за часы, а не недели» (components/09), «Новый франчайзи за часы» (personas U6) и «запуск ≤ 3 дней» / «≤ 3 рабочих дней» (метрика blueprint и гейт фазы 4 плана). Разница между «за часы» и «≤3 рабочих дней» — в разы, при этом эти цифры попадают в инвест-материалы.
• Цитата / доказательство: gap-analysis G7: «Онбординг точки „за день“» ↔ plan/01: «Новая партнёрская точка за ≤3 дня»
• С чем расходится: components/09: «за часы, а не недели»; academic/11: «онбординг точки „за часы“» как требование
• Рекомендация: Развести два показателя: «шаблон точки клонируется за часы» (технический факт, гейт Ф0) и «полный запуск точки ≤ 3 рабочих дней» (продуктовая метрика) — и использовать только их.

F-07 — СРЕДНЕ · Противоречие между документами

• Раздел корпуса: Референс-архитектура, компоненты, blueprint, планы
• Файлы: 01-reference-architecture · components/11-integration-platform · product-blueprint · plan/01
• Суть находки: Открытый API: «с первого дня» и в DoD MVP против P2/фазы 5 в плане. Референс-архитектура заявляет принцип «Открытый API и вебхуки с первого дня», компонент 11 включает чекбокс «Открытый API: токен, вебхук на событие заказа, документация опубликована» в DoD MVP, но blueprint относит «Открытый API и маркетплейс» к P2/фазе 5, а план первых 90 дней и состав MVP фазы 1 API не содержат вовсе.
• Цитата / доказательство: components/11, DoD MVP: «□ Открытый API: токен, вебхук на событие заказа…»
• С чем расходится: product-blueprint: «Открытый API и маркетплейс интеграций — D11, P2»; plan/01 Ф1 без API
• Рекомендация: Переформулировать: «внутренний API контрактов — с фазы 1, публичный маркетплейс партнёров — фаза 5»; убрать API из DoD MVP либо добавить в план фазы 1.

F-08 — СРЕДНЕ · Противоречие между документами

• Раздел корпуса: Рынок, компоненты, инфраструктура, глоссарий
• Файлы: 00-market-landscape · components/01-pos-fiscal · infrastructure/banks-kassa-ofd · glossary
• Суть находки: Сроки обязательности ФФД 1.2 сформулированы тремя разными способами. Market-landscape: «ФФД 1.2 обязателен с 01.02–01.03.2025/2026» — двусмысленная запись, не читаемая однозначно. Компонент 01: «с 01.02.2025 ФФД 1.05 не принимается для новых регистраций; с 01.03.2026 — единственный формат». Инфраструктура: «формат 1.05 выведен с 01.03.2026». Глоссарий сужает требование до «обязательная версия для маркировки», хотя речь о всеобщей обязательности для новых ККТ. Регуляторные даты — ядро продажи «касса из коробки», и их разнобой в маркетинговых материалах недопустим.
• Цитата / доказательство: 00-market-landscape: «ФФД 1.2 обязателен с 01.02–01.03.2025/2026»
• С чем расходится: components/01: «с 01.02.2025… с 01.03.2026 — единственный формат»; glossary: «1.2 — обязательная версия для маркировки»
• Рекомендация: Одна каноническая формулировка с двумя датами (новые регистрации / все кассы) в глоссарии и market-landscape; компонент 01 — источник истины.

F-09 — СРЕДНЕ · Противоречие между документами

• Раздел корпуса: Компоненты, спецификации
• Файлы: components/12-data-model · specs/03-api-contracts
• Суть находки: Контракт создания заказа: guest_phone против guest{phone, consent}, разные enum каналов. Компонент 12 описывает заказ с полями guest_phone?, payment_intent и перечислением каналов, включающим phone. Спецификация 03 — вложенный объект guest {phone, consent: true}, idempotency_key и delivery.slot, которого в модели 12 нет, а канала phone в enum нет. Компонент 02 при этом описывает «заказ по телефону» через колл-центр как полноценный канал. Контракт API и модель данных — два документа, по которым будут писать код, и они уже разные.
• Цитата / доказательство: components/12: «guest_phone?, … payment_intent» ↔ specs/03: «"guest": { "phone": …, "consent": true }»
• С чем расходится: channel enum: components/12 содержит phone, specs/03 — нет
• Рекомендация: Синхронизировать: specs/03 — источник контракта, components/12 — модель; добавить slot и канал phone в модель, зафиксировать consent-поле в модели данных (требование 152-ФЗ).

F-10 — СРЕДНЕ · Противоречие между документами

• Раздел корпуса: Резюме, gap-анализ, рынок, конкуренты
• Файлы: executive-summary · gap-analysis · 00-market-landscape · competitors/rkeeper · competitors/1c
• Суть находки: Тарифы «тяжёлых» систем 8–10+ тыс ₽/мес против собственных данных аудита. Резюме и gap-анализ утверждают, что корпоративная глубина стоит «8–10+ тыс ₽/мес за кассу», а market-landscape — что МСБ-касс «дешевле в 3–5 раз». Но собственные файлы конкурентов дают r_keeper Cloud «от 4 085 ₽/мес» и 1С:Фреш «от 32 200 ₽/год (~2 684 ₽/мес)». Вилка «в 3–5 раз дешевле» ломается: Quick Resto 4 990 ₽ против r_keeper Cloud 4 085 ₽ — разница 1,2×, то есть конкурент дешевле части МСБ-решений.
• Цитата / доказательство: executive-summary: «корпоративные тарифы (8–10+ тыс ₽/мес за кассу)»
• С чем расходится: competitors/rkeeper: «r_keeper Cloud — от 4 085 ₽/мес»; competitors/1c: «1С:Фреш от 32 200 ₽/год»
• Рекомендация: Уточнить формулировки: «флагманские тарифы iiko Pro 8 600–10 600 ₽/мес» вместо обобщения про все «тяжёлые»; для вилки «дешевле в 3–5 раз» указать сравнение с конкретными тарифами.

F-11 — СРЕДНЕ · Пробел/устаревание

• Раздел корпуса: Аудит-отчёт
• Файлы: research/audit-report
• Суть находки: Ревизия №1 описывает корпус из 30 документов — в корпусе их 70. Аудит-отчёт заявляет «30 документов на момент ревизии», 352 внешних и 41 внутреннюю ссылку, оценку «полнота покрытия доменов 10/10, готовность к публикации 9/10» — но половина текущего корпуса (17 академических разборов, 3 плана, 4 SaaS-страницы, инфраструктура, терминология, схема-каталог) появилась после ревизии и в ней не учтена. Вердикт «корпус полон и готов к публикации» не пересматривался. Также отчёт утверждает «часть вендоров цены не раскрывает (Revel, TouchBistro)», тогда как в файле TouchBistro указана цена «от $69/мес за терминал».
• Цитата / доказательство: audit-report: «30 документов на момент ревизии»
• С чем расходится: Фактически в корпусе 70 страниц (68 в sitemap + /demo/ + saas/03-role-scenarios)
• Рекомендация: Провести ревизию №2 с новым подсчётом документов и ссылок; обновить раздел ограничений (TouchBistro); перенести оценки «до/после» в архивную секцию.

F-12 — СРЕДНЕ · Противоречие между документами

• Раздел корпуса: Индекс, SaaS
• Файлы: index · saas/02-demo-cabinet · saas/03-role-scenarios
• Суть находки: Числа демо: заявлено 30 экранов и 66 сценариев — в таблице покрытия 34 и 77. Индекс и спецификация демо-кабинета повторяют «30 экранов, 10 ролей, 66 интерактивных сценариев», но собственная сводная таблица раздела 13 страницы role-scenarios суммируется в 34 экрана (3+2+8+3+2+5+1+2+6+2) и 77 интерактивных действий (8+7+11+6+5+9+5+7+10+9). Либо таблица включает что-то сверх «30 экранов полного периметра», либо цифры устарели после итерации аудита.
• Цитата / доказательство: saas/03 §13: сумма по ролям = 34 экрана, 77 действий
• С чем расходится: index: «30 экранов полного периметра»; saas/02: «30 экранов, 10 ролей… 66 интерактивных сценариев»
• Рекомендация: Пересчитать фактические маршруты демо и привести три документа к одним числам; в таблице §13 добавить строку «Итого».

F-13 — СРЕДНЕ · Противоречие между документами

• Раздел корпуса: SaaS
• Файлы: saas/02-demo-cabinet · saas/00-platform-map · saas/03-role-scenarios
• Суть находки: «Итого 10 ролей» при девяти строках в таблице ролей — потерян Закупщик. Таблица ролей в демо-кабинете содержит 9 строк (Гость, Кассир, Управляющий, Повар, Курьер, Поставщик, Франчайзи, Менеджер УК, Собственник) при выводе «Итого 10 ролей» — десятая роль, Закупщик, в таблице отсутствует, хотя есть в role-scenarios (раздел 7) и в аудитории ERP («Повара, курьеры, закупщики, поставщики») той же страницы карты платформы. В диаграмме PEOPLE (saas/00) Закупщика тоже нет.
• Цитата / доказательство: saas/02 §2: таблица из 9 строк + «Итого 10 ролей»
• С чем расходится: saas/03 §7: полноценный раздел «Закупщик (erp.lovii.ru)»
• Рекомендация: Добавить строку Закупщика в таблицу ролей saas/02 и в диаграмму PEOPLE saas/00.

F-14 — СРЕДНЕ · Противоречие между документами

• Раздел корпуса: Спецификации, компоненты, SaaS
• Файлы: specs/02-processes · components/03-kitchen-kds · components/12 · saas/01-information-flow
• Суть находки: Момент списания по ТТК: при пробитии чека против при статусе «готов». Последовательность в specs/02 отправляет «списание ингредиентов по ТТК» сразу от кассы (при пробитии), а компонент 03 прямо требует противоположного: «статус „готов“ триггерит списание по ТТК, а не момент пробития». Компонент 12, saas/01 и демо (сценарий CH2) поддерживают списание по готовности. Это влияет на фудкост при отменах и возвратах — по specs/02 продукты спишутся на незакупленное блюдо.
• Цитата / доказательство: specs/02 §1: «Касса->>Склад: списание ингредиентов по ТТК»
• С чем расходится: components/03 §4: «статус „готов“ триггерит списание по ТТК, а не момент пробития»
• Рекомендация: Принять списание по готовности (большинство документов и демо уже так работают), поправить схему specs/02.

F-15 — СРЕДНЕ · Внутреннее противоречие

• Раздел корпуса: Платёжная инфраструктура
• Файлы: infrastructure/banks-kassa-ofd · plan/02-systems-roadmap
• Суть находки: Вилки цен на эквайринг, кассы, ФН и облачные кассы расходятся с планом систем. Внутри самого файла инфраструктуры: текст «СБП у всех крупных банков 0,4–0,7%» против таблицы «Сбер 0,3–0,7%»; «Касса (оборудование) 12 000–60 000 ₽» против «ККТ 20–60 тыс ₽/шт» в плане систем (при этом собственная строка таблицы MSPOS-K «от 15 000 ₽» не попадает ни в одну вилку); ФН «~8 500–15 000 ₽» против «~10–15 тыс ₽»; облачная касса «1 500–3 900 ₽/мес» против «~1,5–3 тыс ₽/мес».
• Цитата / доказательство: infrastructure: «СБП у всех крупных банков 0,4–0,7%» ↔ таблица: «Сбер… 0,3–0,7%»
• С чем расходится: plan/02: «ККТ 20–60 тыс ₽/шт; ФН ~10–15 тыс ₽; облачная касса ~1,5–3 тыс ₽/мес»
• Рекомендация: Вынести эталонные вилки в инфраструктуру, план систем — на ссылку; согласовать нижние границы с реальными моделями из собственной таблицы.

F-16 — СРЕДНЕ · Противоречие между документами

• Раздел корпуса: Конкуренты
• Файлы: competitors/saby-presto · competitors/ru-smaller · competitors/toast · competitors/square-touchbistro-revel
• Суть находки: «Ценовой пол рынка ~2 000 ₽/мес» против моделей с нулевой ценой входа. Аудит Saby Presto формулирует «ценовой пол рынка — ~2 000 ₽/мес», но собственные файлы корпуса фиксируют модели «0 ₽/мес за ПО» (Fusion POS), Toast «$0 старт» и Square Free (бесплатный тариф). Ценовая модель lovii («бесплатный вход») опирается как раз на нулевой пол — формулировка Saby подрывает собственный вывод.
• Цитата / доказательство: saby-presto: «Ценовой пол рынка — ~2 000 ₽/мес»
• С чем расходится: ru-smaller: Fusion POS «0 ₽/мес за ПО»; toast: «$0/мес старт»
• Рекомендация: Переформулировать: «пол платных тарифов ~2 000 ₽/мес; мировой стандарт — бесплатный вход с монетизацией платежей».

F-17 — СРЕДНЕ · Противоречие между документами

• Раздел корпуса: Аудит-отчёт, конкуренты
• Файлы: research/audit-report · competitors/square-touchbistro-revel
• Суть находки: «TouchBistro цену не раскрывает» против цены в собственном файле. Аудит-отчёт в разделе ограничений пишет, что «часть вендоров цены не раскрывает (Revel, TouchBistro-сеть)», но файл конкурентов приводит цену TouchBistro: «от $69/мес за терминал + аддоны». Расхождение дискредитирует раздел «ограничения аудита» — а именно на него ссылается методология.
• Цитата / доказательство: audit-report §5: «часть вендоров цены не раскрывает (Revel, TouchBistro-сеть)»
• С чем расходится: square-touchbistro-revel: «TouchBistro: от $69/мес за терминал + аддоны»
• Рекомендация: Обновить список нераскрытых цен (оставить Revel, если цены действительно нет) после ревизии №2.

F-18 — СРЕДНЕ · Фактическая ошибка

• Раздел корпуса: Академические разборы
• Файлы: academic/08-clv-models
• Суть находки: Неверная атрибуция модели BG/BB: авторы, год и класс отношений. Таблица моделей в разборе 8 приписывает BG/BB «Fader, Хардти, Ли (2007)» и классифицирует её для «договорных (контрактных) отношений». Модель BG/BB (Beta-Geometric/Beta-Bernoulli) предложена Fader, Hardie и Shang (2010) именно для неконтрактных отношений с дискретными транзакциями; контрактный аналог — sBG (Fader & Hardie, 2007). Ошибка в академическом документе, на который опирается раздел лояльности.
• Цитата / доказательство: academic/08: «Fader, Хардти, Ли (2007) | Договорные (контрактные) отношения»
• С чем расходится: Fader P., Hardie B., Shang K. (2010), Marketing Science — BG/BB для неконтрактных дискретных транзакций
• Рекомендация: Исправить строку таблицы: «BG/BB — Fader, Hardie, Shang (2010), неконтрактные дискретные»; контрактные модели — sBG (Fader & Hardie 2007).

F-19 — СРЕДНЕ · Внутреннее противоречие

• Раздел корпуса: Академические разборы
• Файлы: academic/01-management-accounting · academic/02-unit-economics
• Суть находки: Правило «30/30/30/10» противоречит собственным бенчмаркам корпусов. Оба разбора цитируют «классическое правило 30/30/30/10» (аренда+ЖКХ / ФОТ / фудкост / прибыль), но таблица бенчмарков того же разбора 1 даёт аренду 10–15%, а фудкост-ориентир — 25%. Если следовать правилу, аренда должна занимать 30% выручки — вдвое больше собственного бенчмарка. Правило в такой расшифровке не выдерживает даже соседней таблицы.
• Цитата / доказательство: academic/02: «Правило „30/30/30/10“ (аренда+ЖКХ / ФОТ / фудкост / прибыль) — классический целевой баланс»
• С чем расходится: academic/01, таблица: «Аренда и коммунальные 10–15%»; ориентир фудкоста 25%
• Рекомендация: Привести каноническую расшифровку (например, ФОТ 30% / продукты ~30% / прочие операционные ~30% / прибыль 10%) или заменить правило собственным целевым балансом.

F-20 — СРЕДНЕ · Арифметическая ошибка

• Раздел корпуса: Академические разборы
• Файлы: academic/02-unit-economics
• Суть находки: «1 п.п. фудкоста = ±10% прибыли» — при заданной рентабельности 8% это 12,5%. Разбор 2 утверждает: 1 п.п. фудкоста при выручке 5 млн ₽/мес = 50 тыс ₽/мес чистой прибыли, «при рентабельности 8% это ±10% прибыли точки». Прибыль при 8% от 5 млн = 400 тыс ₽/мес; 50/400 = 12,5%. Цифра ±10% соответствовала бы рентабельности 10%, а не 8%. Пример — один из главных аргументов продажи платформы, и его арифметика должна сходиться.
• Цитата / доказательство: «при рентабельности 8% это ±10% прибыли точки» (academic/02 §2)
• С чем расходится: 50 000 / (5 000 000 × 0,08) = 12,5%
• Рекомендация: Исправить на «±12,5% прибыли» либо изменить базовую рентабельность примера на 10%.

F-21 — СРЕДНЕ · Противоречие между документами

• Раздел корпуса: Терминология, компоненты
• Файлы: terminology-crm-erp · components/09-franchise-network
• Суть находки: Франшиза: «надстройка над обоими классами» против «не надстройка, а способ существования». Терминологический разбор относит франшизу к «контуру управления сетью (надстройка над обоими классами)», тогда как компонент 09 декларирует противоположное: «Франшиза — не „надстройка“, а способ существования продукта». Для архитектуры это не словесность: надстройка встраивается поверх готовой системы, «способ существования» требует иерархии тенантов с первого дня (что и заявлено в фазе 0).
• Цитата / доказательство: terminology-crm-erp §6.2: «Контур управления сетью/франшизой» (надстройка над обеими классами)
• С чем расходится: components/09 §6: «Франшиза — не „надстройка“, а способ существования продукта»
• Рекомендация: Синхронизировать: франшизная иерархия — часть ядра с Ф0 (как в blueprint), термин «надстройка» убрать из терминологии.

F-22 — СРЕДНЕ · Противоречие между документами

• Раздел корпуса: Персоны, терминология
• Файлы: 02-personas-cjm · terminology-franchise
• Суть находки: Периодичность роялти: еженедельно у одной персоны, ежемесячно у другой и в терминологии. Персона 4 («Продавец-франчайзи») «еженедельно видит роялти-счёт», персона 5 «в конце месяца закрывает роялти», терминологический разбор франшизы описывает роялти как ежемесячный платёж. Компонент 09 и specs/02 периодичность вообще не фиксируют, хотя от неё зависит дизайн биллинга и актов сверки.
• Цитата / доказательство: 02-personas-cjm П4: «Еженедельно видит роялти-счёт»
• С чем расходится: 02-personas-cjm П5: «В конце месяца закрывает роялти»; terminology-franchise: ежемесячные роялти
• Рекомендация: Зафиксировать расчётный период роялти (например, расчёт — понедельный по фискальной выручке, закрытие и счёт — месячный) в компоненте 09 и синхронизировать персоны.

F-23 — СРЕДНЕ · Терминология

• Раздел корпуса: SaaS, терминология
• Файлы: saas/00-platform-map · terminology-crm-erp · components/06
• Суть находки: Границы «операционного» и «гостевого» контуров не сведены между картой и терминологией. Карта платформы называет «операционным контуром» erp.lovii.ru (кухня, склад, поставщики), терминологический разбор использует «операционный CRM» для фронтовых клиентских процессов, а компонент 06 называет контуром «CRM, лояльность, отзывы». «Гостевой контур» — это app.lovii.ru в карте, но в терминологии гостевой разбор описывает гостевой CRM иначе. Читатель корпуса не может однозначно сопоставить контуры между документами.
• Цитата / доказательство: saas/00: «erp.lovii.ru — операционный контур»
• С чем расходится: terminology-crm-erp §3.4: «операционный CRM»; components/06: «CRM гостя, лояльность…»
• Рекомендация: Добавить в глоссарий три официальных названия контуров (гостевой/app, клиентский/crm, операционный/erp) и пройтись по документам с заменой синонимов.

F-24 — СРЕДНЕ · Пробел/устаревание

• Раздел корпуса: Референс-архитектура, модель данных
• Файлы: 01-reference-architecture · components/12-data-model · specs/01-domain-model
• Суть находки: FranchiseAccount — «ключевая сущность» референс-модели — отсутствует в модели данных. Референс-архитектура в списке ключевых сущностей называет FranchiseAccount («УК видит агрегированные данные точек договора, роялти считается от выручки»), но в модели данных (components/12) и ER-схемах (specs/01) этой сущности нет — там Tenant, FranchiseAgreement, RoyaltyInvoice. Часть атрибутов покрывается договором, но часть (агрегаты по точкам договора) — реализация не имеет.
• Цитата / доказательство: 01-reference-architecture §3: «FranchiseAccount — УК видит агрегированные данные точек договора…»
• С чем расходится: components/12/specs/01: Tenant, FranchiseAgreement, RoyaltyInvoice — FranchiseAccount отсутствует
• Рекомендация: Либо добавить FranchiseAccount в модель, либо пометить в ref-arch, что роль сущности исполняет FranchiseAgreement + проекции витрин.

F-25 — СРЕДНЕ · Счётность

• Раздел корпуса: Резюме, индекс
• Файлы: executive-summary · index · research/audit-report
• Суть находки: «Аудит аналогов: 14 классов систем» против 13 файлов и 11 карточек навигации. Резюме говорит «аудит аналогов (14 классов систем)», в навигации корпуса 11 карточек раздела «Аудиты аналогов», на диске 13 файлов конкурентов (при этом ru-smaller покрывает 4 системы, square-touchbistro-revel — 3). Ни одно из чисел не сходится с остальными, и «класс системы» нигде не определён.
• Цитата / доказательство: executive-summary: «Что показал аудит аналогов (14 классов систем)»
• С чем расходится: index: 11 карточек конкурентов; файлов: 13
• Рекомендация: Ввести определение «класса» и посчитать одинаково во всех трёх местах, либо перейти к формулировке «13 аудитов, 30+ вендоров».

F-26 — СРЕДНЕ · Противоречие между документами

• Раздел корпуса: Компоненты, конкуренты
• Файлы: components/02-order-channels · competitors/middleware-delivery
• Суть находки: Otter: «100+ интеграций» против «POS-интеграции с 20+ кассовыми системами». Компонент 02 приводит Otter со «100+ интеграциями», файл middleware — «POS-интеграции с 20+ кассовыми системами». Возможно, первый — все интеграции (включая агрегаторы), второй — только POS, но корпус не разграничивает метрики, и читатель видит противоречие в 5 раз.
• Цитата / доказательство: components/02: «Otter — … 100+ интеграций»
• С чем расходится: middleware-delivery: «Otter: POS-интеграции с 20+ кассовыми системами»
• Рекомендация: Разграничить метрики: «20+ POS-интеграций, 100+ агрегаторов/каналов (по данным вендора)» — или привести к одному знаменателю.

F-27 — СРЕДНЕ · Сбита база процента

• Раздел корпуса: Компоненты
• Файлы: components/03-kitchen-kds · components/07-hr-staff · academic/01
• Суть находки: «25–35% себестоимости» на кухне против 25–35% выручки ФОТ в соседних документах. Введение компонента 03: «место, где теряются или зарабатываются 25–35% себестоимости». В остальных документах корпуса 25–35% — это диапазон ФОТ от выручки (components/07, academic/01), а фудкост измеряется от выручки (12–40%, ориентир 25%). «Проценты себестоимости» — другая база, и фраза в текущем виде либо ошибочна, либо нечитаема.
• Цитата / доказательство: components/03, вводный абзац: «теряются или зарабатываются 25–35% себестоимости»
• С чем расходится: components/07: «(25–35% выручки)» о ФОТ; glossary: фудкост = себестоимость продуктов в % от выручки
• Рекомендация: Переформулировать: «где теряются или зарабатываются 5–10 п.п. фудкоста» или указать корректную базу.

Низкие (16)

F-28 — НИЗКО · Фактическая ошибка

• Раздел корпуса: Академические разборы
• Файлы: academic/03-service-quality
• Суть находки: DINESERV: 28 утверждений против 29 в первоисточнике. Разбор 3 описывает DINESERV как «инструмент — 28 утверждений». В первоисточнике (Stevens, Knutson & Patton, 1995, Cornell HRA Quarterly) анкета содержит 29 пунктов (проверено по публикациям первоисточника). Для документа, претендующего на академическую точность, число пунктов инструмента — проверяемая деталь.
• Цитата / доказательство: academic/03: «инструмент DINESERV — 28 утверждений»
• С чем расходится: Stevens, Knutson & Patton (1995): «The 29-item DINESERV questionnaire»
• Рекомендация: Исправить на 29; при желании добавить сноску о сокращённых адаптациях.

F-29 — НИЗКО · Терминология

• Раздел корпуса: Академические разборы
• Файлы: academic/17-franchise-law-comparative
• Суть находки: «Конкурсное право ЕС» вместо конкурентного (антимонопольного). Разбор 17 пишет «Конкурсное право ЕС касается вертикальных соглашений франшизы». Вертикальные соглашения регулирует конкурентное (антимонопольное) право (ст. 101 TFEU, регламент о вертикальных соглашениях); конкурсное право — это процедура банкротства. Смысловая ошибка в правовом разборе.
• Цитата / доказательство: academic/17: «Конкурсное право ЕС касается вертикальных соглашений»
• С чем расходится: Регламент (ЕС) 2022/720 о вертикальных соглашениях — акт конкурентного права
• Рекомендация: Заменить на «конкурентное (антимонопольное) право».

F-30 — НИЗКО · Фактическая ошибка

• Раздел корпуса: Академические разборы
• Файлы: academic/17-franchise-law-comparative
• Суть находки: «Правило ФТК (1979, обновлено 2010)» — поправки приняты в 2007. Разбор 17 указывает обновление Правила о франшизе ФТК США в 2010 году. Поправки приняты в 2007 (16 CFR Part 436) с обязательным применением к франшизам с 1 июля 2008. Год в квадратных скобках — типичная проверяемая деталь для юридических читателей.
• Цитата / доказательство: academic/17: «Правило ФТК о франшизе (1979, обновлено 2010)»
• С чем расходится: Amended Franchise Rule, 16 CFR Part 436 (2007), обязательна с 01.07.2008
• Рекомендация: Исправить на «1979, в действующей редакции 2007 (применение с 2008)».

F-31 — НИЗКО · Коллизия акронима

• Раздел корпуса: Академические разборы, глоссарий
• Файлы: academic/06-food-safety-terminology · glossary
• Суть находки: ККТ в разборе 6 — «критическая контрольная точка», в глоссарии — кассовая техника. Разбор 6 вводит «Критическая контрольная точка (ККТ/CCP)» — русский акроним для CCP (Critical Control Point) из ХАССП, совпадающий с устоявшимся в корпусе ККТ = контрольно-кассовая техника. Коллизия тиражируется в карте документов и программе разборов. В русскоязычной практике ХАССП используется КТК (критическая точка контроля) или ККТ расшифровывают как «критическая контрольная точка» только с пометкой.
• Цитата / доказательство: academic/06: «Критическая контрольная точка (ККТ/CCp)»
• С чем расходится: glossary: «ККТ — Контрольно-кассовая техника (касса) из реестра ФНС»
• Рекомендация: Переименовать в КТК/CCP или «критическая точка контроля (КТП)» по всему корпусу.

F-32 — НИЗКО · Расхождение

• Раздел корпуса: Спецификации, компоненты
• Файлы: specs/01-domain-model · components/12-data-model · components/05
• Суть находки: StockMovement: 8 типов в спецификации против 9 в модели (writeoff_staff); вручение — только фото, без кода. В specs/01 перечислено 8 типов складских движений, в components/12 — 9 (добавлен writeoff_staff — списание на персонал, критичное для антифрода). Компонент 05 обещает подтверждение доставки «фото или код», но в модели DeliveryAssignment есть только proof_photo — код вручения не предусмотрен.
• Цитата / доказательство: specs/01: 8 типов движений; components/12: «receive | sale_writeoff | production_in | production_out | transfer | writeoff_spoilage | writeoff_staff | inventory_adjust | return»
• С чем расходится: components/05: «доставлен — фото или код» ↔ components/12: только proof_photo
• Рекомендация: Добавить writeoff_staff в specs/01 и proof_code в модель; синхронизировать перечисления.

F-33 — НИЗКО · Дрейф имён

• Раздел корпуса: Архитектура, компоненты, SaaS, спецификации
• Файлы: 01-reference-architecture · components/07 · saas/02 · specs/00
• Суть находки: Четыре несовпадающих ролевых набора и дрейф названий ролей. Референс-архитектура описывает 11 ролей (включая Бармена, Маркетолога УК, Бухгалтера), компонент 07 — 8, демо — 10, контекст спецификации 00 — 7. Названия плавают: «Владелец»/«Собственник», «Менеджер УК»/«Операционный директор УК», «Франчайзи»/«Продавец-франчайзи», «Кассир/официант»/«Кассир». В сводной таблице персон есть колонка «Кассир», хотя персоны с таким именем в документе нет.
• Цитата / доказательство: ref-arch §4: 11 ролей; specs/00 §1: 7 ролей; demo: 10 ролей; comp_07: 8 ролей
• С чем расходится: personas: сводная таблица содержит колонку «Кассир» без одноимённой персоны
• Рекомендация: Завести единый реестр ролей (id + каноническое имя) в глоссарии и ссылаться на него; в демо указывать, какие роли референса пока не покрыты.

F-34 — НИЗКО · Противоречие между документами

• Раздел корпуса: Спецификации
• Файлы: specs/04-deployment-offline · product-blueprint
• Суть находки: «Торговать без интернета неограниченно долго» против норматива офлайн-смены 8 часов. Спецификация 04 обещает «торговать без интернета неограниченно долго», тогда как blueprint задаёт измеримую метрику «офлайн-автономность кассы — 8 часов продаж без облака». Обещание «неограниченно» не проверяемо и противоречит собственному NFR.
• Цитата / доказательство: specs/04: «торговать без интернета неограниченно долго»
• С чем расходится: product-blueprint §5: «офлайн-автономность кассы — 8 часов продаж без облака»
• Рекомендация: Заменить на норматив 8 часов + деградация функциональности после (как в планах).

F-35 — НИЗКО · Неточность

• Раздел корпуса: Конкуренты, gap-анализ
• Файлы: competitors/poster · gap-analysis
• Суть находки: Poster: «100 товаров» превращается в «100 техкарт», три валюты в одной сетке, вывод не сходится с тарифами. У Poster в файле конкурентов лимит «100 товаров/ТТК», gap-анализ уже приводит его как «100 техкарт на €29». Тарифная сетка перемешивает валюты (Mini €29, Network «от $99/мес», отдельные рублёвые/гривневые тарифы «от ~$14»), а итоговый вывод «€30–70/мес» не покрывает нижнюю границу €29.
• Цитата / доказательство: gap-analysis G3: «урезают лимитами (100 техкарт на €29 у Poster)»
• С чем расходится: competitors/poster: «100 товаров/ТТК»; сетка €29/$99/₽/₴; вывод «€30–70»
• Рекомендация: Унифицировать валюту сетки (или дать параллельные рублёвые тарифы), поправить вывод на «€29–69», сохранить «товары/ТТК» без подмены термина.

F-36 — НИЗКО · Расхождение

• Раздел корпуса: SaaS
• Файлы: saas/00-platform-map · saas/03-role-scenarios
• Суть находки: Франчайзи: только crm в сценариях против crm+erp в демо; заказы/отзывы в интро ERP против таблицы CRM. В saas/03 раздел «Франчайзи (crm.lovii.ru)» ограничивает роль клиентским контуром, тогда как демо и карта дают франчайзи «crm + erp». Интро saas/00 относит «отзывы» к операционному контуру, таблица §2 той же страницы — к CRM. Кабинет УК в таблице «внутри erp/crm», в демо это отдельный #/uk.
• Цитата / доказательство: saas/03 §9: «Франчайзи (crm.lovii.ru)»
• С чем расходится: saas/00 §3: «Продавец-франчайзи | crm + erp»
• Рекомендация: Провести ревизию контуров по всем ролям в saas/00–03 и привести к одному распределению.

F-37 — НИЗКО · Пробел

• Раздел корпуса: SaaS, инфраструктура
• Файлы: saas/03-role-scenarios · infrastructure/banks-kassa-ofd
• Суть находки: Правило мок-банка «сумма кратна 997 → код 51» не описано в контракте моков. Сценарий отказа оплаты в демо ссылается на «контракты из платёжной инфраструктуры», но контракт мок-сервисов (§7 infrastructure) правило отказа с кодом 51 и кратностью 997 не описывает. Спецификация демо заявляет поведение, которого нет в спецификации контракта.
• Цитата / доказательство: saas/03 S2: «сумма кратна 997 → отказ, код 51»
• С чем расходится: infrastructure §7: контракт мок-банка без правила 997/51
• Рекомендация: Дописать правило в контракт мок-банка (или удалить из сценария).

F-38 — НИЗКО · Структура

• Раздел корпуса: Структура сайта
• Файлы: sitemap.xml · /demo/ · saas/03-role-scenarios
• Суть находки: sitemap.xml не содержит двух страниц, включая полноценную страницу сценариев. В sitemap.xml 68 URL, но /research/saas/03-role-scenarios/ (13 тыс. знаков контента, связана из каталога схем и навигации) и /demo/ в нём отсутствуют. /demo/ — интерактивное JS-приложение, пустое для поисковых систем (текст извлекается только скриптами). Индекс же ссылается на обе страницы.
• Цитата / доказательство: sitemap.xml: 68 URL; HTTP 200 для /demo/ и /research/saas/03-role-scenarios/
• С чем расходится: index: ссылки на research/saas/03-role-scenarios/ и /demo/
• Рекомендация: Перегенерировать sitemap; для /demo/ добавить SSR-заглушку с описанием и ссылками (SEO и доступность).

F-39 — НИЗКО · Пробел

• Раздел корпуса: Весь корпус
• Файлы: 68 страниц корпуса · 13 файлов конкурентов
• Суть находки: Нет сквозных метаданных статуса/даты страниц; факт-маркеры без списка источников. Ни одна страница не имеет шапки со статусом/датой ревизии (даты встречаются только в 3 файлах) — при живом корпусе читатель не может отличить актуальный документ от устаревшего (пример F-11). Во всех 13 файлах конкурентов числовые факт-маркеры 1, 2, 3… не сопровождаются секцией «Источники» (список есть только у инфраструктуры); в разборах 1, 2, 4 — висячие сноски и источники-заглушки без ссылок.
• Цитата / доказательство: Проверка корпуса: строка «Статус:» в начале страницы — 0 из 70
• С чем расходится: audit-report заявляет «все ключевые факты с цитатами»
• Рекомендация: Ввести метаданные (статус, дата ревизии, владелец) в шапку каждой страницы; добавить секцию «Источники» в файлы конкурентов.

F-40 — НИЗКО · Стиль/опечатки

• Раздел корпуса: Несколько разделов
• Файлы: crm-vs-erp · academic/08 · components/05 · components/04 · academic-research-agenda · gap-analysis · saas/02
• Суть находки: Опечатки и непоследовательная транслитерация бренда. «Отзыв госта» (crm-vs-erp), «количества покуток» (academic/08), «правилно-ориентированное» (components/05), «горяней» (components/04), «Кодекс Алиментариус (ФАТ/ВОЗ)» вместо ФАО (программа разборов). Бренд пишется по-разному: lovii / «ловии» (quadrant-диаграмма gap-анализа) / «Тенант УК „Ловии“» (демо-данные).
• Цитата / доказательство: gap-analysis quadrantChart: «quadrant-2 Цель ловии»
• С чем расходится: Остальной корпус: «lovii»
• Рекомендация: Массовая вычитка; закрепить написание бренда «lovii» (кириллические варианты — только в кавычках при первом упоминании).

F-41 — НИЗКО · Источники

• Раздел корпуса: Академические разборы
• Файлы: academic/04-personal-data-loyalty
• Суть находки: Источники-заглушки без ссылок и штраф, требующий юрверификации. Список источников разбора 4 содержит названия без ссылок («Изменения 152-ФЗ в 2025…», «Документы по 152-ФЗ в 2026…»), а штраф «обработка без законного основания — до 300 тыс ₽» не подтверждён источником и может смешиваться со штрафом за неуведомление. Для регуляторного чек-листа платформы это риск прямых финансовых последствий.
• Цитата / доказательство: academic/04, источники: «Изменения 152-ФЗ в 2025 году: …» (без ссылки)
• С чем расходится: Стандарт корпуса: «352 ссылки на первоисточники» (audit-report)
• Рекомендация: Заменить заглушки ссылками на первоисточники (152-ФЗ, КоАП 13.11); верифицировать штрафные суммы.

F-42 — НИЗКО · Неточность

• Раздел корпуса: Терминология, академия
• Файлы: terminology-franchise · academic/17
• Суть находки: Обязательность товарного знака связана с «частью четвёртой ГК» — глава 54 в части второй. Терминологический разбор связывает требование регистрировать товарный знак в договоре коммерческой концессии с «введением части четвёртой ГК» (о ней как об части о результатах интеллектуальной деятельности). Глава 54 «Коммерческая концессия» находится в части второй ГК (ст. 1027–1040); изменение режима товарных знаков — ФЗ-160 от 18.07.2008. Ссылка на часть кодекса неточна.
• Цитата / доказательство: terminology-franchise: обязательность товарного знака — «с введением части четвёртой ГК»
• С чем расходится: ГК РФ, глава 54 — часть вторая (ст. 1027); ФЗ-160 от 18.07.2008
• Рекомендация: Исправить ссылку на часть вторую ГК РФ и указать ФЗ-160.

F-43 — НИЗКО · Формулировка

• Раздел корпуса: Глоссарий, компоненты
• Файлы: glossary · components/01 · components/10
• Суть находки: Глоссарий сужает обязательность ФФД 1.2 до «маркировки». Глоссарий определяет ФФД 1.2 как «обязательная версия для маркировки», тогда как компоненты 01 и 10 описывают всеобщую обязательность для новых ККТ (независимо от товара) с 2025–2026 гг. Формулировка глоссария может привести к решению «у нас нет маркировки — ФФД 1.2 не нужен».
• Цитата / доказательство: glossary: «ФФД — Формат фискальных документов; 1.2 — обязательная версия для маркировки»
• С чем расходится: components/01: «с 01.03.2026 — единственный формат»
• Рекомендация: Дополнить определение глоссария: «обязательная версия для ККТ, торгующих маркированными товарами; с 01.03.2026 — единственная для новых регистраций».

Позитивные проверки

Область сверки	Что подтверждено
Глоссарий и терминология	Определения фудкоста, ТТК, роялти, паушального взноса, франчайзера/УК согласованы между глоссарием и терминологическими разборами; термин «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. Обход корпуса	Загрузка 68 страниц по sitemap.xml + 2 страницы сверх карты (демо и saas/03), извлечение чистого текста (~550 тыс. знаков).
2. Автоматические проверки	Разрешение 1 200+ внутренних ссылок (относительные пути), якоря, статус-метки и даты, сравнение sitemap с фактическими страницами.
3. Каноническая база	Ручное чтение ядра корпуса (сводки, рынок, blueprint, планы, спецификации, глоссарий) с фиксацией эталонных фактов и цифр.
4. Факт-листы разделов	Параллельная обработка компонентов (12), академических разборов (17), конкурентов и инфраструктуры (14), терминологии и схем (8+): каждое число, определение и ссылка — в реестр.
5. Сквозная сверка	Сопоставление факт-листов между собой и с канонической базой; верификация каждой гипотезы противоречия по исходному тексту; выборочная проверка внешних первоисточников (DINESERV, ФТК, 152-ФЗ).
Границы аудита	Проверялась внутренняя согласованность корпуса; внешние первоисточники сверялись выборочно. Живое тестирование демо и конкурентов не входило в объём. Рыночные цифры (оборот, число заведений) на корректность источников не перепроверялись.
Оценка серьёзности	КРИТИЧНО — блокирует разработку или искажает юридический смысл; СРЕДНЕ — дезориентирует читателя/инвестора/команду; НИЗКО — формальные дефекты и гигиена.

Файлы аудита

• Реестр находок (XLSX)
• Отчёт (DOCX)