Реестр блокеров MVP

Актуализация 09.09.2026

Приоритет имеют актуальные решения и перечень модулей. Натальная карта остаётся точным расчётом; нумерология и Human Design включены как LLM-сценарии с точными вспомогательными функциями. Алгоритмы выбирает команда. OpenRouter выбран шлюзом переключения моделей, токен получен. Приняты free/paid и скидка 40% на первый месяц; цена и квоты ещё открыты. Оферта и privacy пока заменяются заглушками для разработки. Матрица судьбы и админ-панель остаются pending.

Ниже сохранены детали предыдущего baseline. Формулировки о natal-only, ожидании алгоритмов от заказчика, неполученном токене, OpenRouter только для eval и неутверждённой скидке заменены решениями от 09.09.2026. Это изменение документации, а не отчёт о готовой реализации.

Исторический статус на 2026-09-04: план разрешения принят и уточнён по итогам звонка с заказчиком. Архитектурных блокеров для текущего backend baseline нет. Состав расчётных модулей первого MVP и включение админ-панели в текущий договор ожидают письменного подтверждения заказчика; до него эти функции не должны неявно расширять реализацию. Часть решений принята как временная методика v0; она реализуется через заменяемые модули и обязательно проверяется по pre-pilot checklist перед внешним пилотом.

В подробных карточках сохранены исходная проблема и формулировка «что блокировалось» для контекста. Текущий статус определяется сводной таблицей: accepted/provisional разрешает проектирование и реализацию, а невыполненный pre-pilot-критерий запрещает только внешний запуск соответствующей функции.

Уровни

• accepted — предложенный default принят и становится текущим решением.
• provisional — принято рабочее решение v0, которое можно реализовывать, но нужно перепроверить до пилота.
• pre-pilot — внутреннюю разработку не блокирует, однако остаётся обязательным gate перед внешним запуском.
• pending — направление обсуждено, но состав текущего MVP или обязательные параметры ещё не утверждены.
• excluded — функция явно исключена из MVP.

Сводка

ID	Принятое направление	Состояние
BLK-01	KarmaCode/TЗ как baseline; консультации без chat/video/calendar	accepted
BLK-02	без точного времени астрология и Human Design заблокированы	accepted
BLK-03	методика natal-v1 из документа расчёта	accepted
BLK-04	Professional License выбрана по направлению; покупка обязательна до запуска	accepted + pre-pilot
BLK-05	provider adapter + immutable place/timezone snapshot	accepted
BLK-06	Нумерология через LLM; точные формулы выбирает команда	accepted + pre-pilot
BLK-07	Human Design через LLM и точные функции; методику выбирает команда	accepted + pre-pilot
BLK-08	заменяемый destiny-matrix-22-v0; включение в первый MVP уточняется	provisional/pending
BLK-09	оси и evidence mapping версионируются и не определяются моделью	accepted
BLK-10	OpenRouter — шлюз смены моделей; токен получен	accepted + pre-pilot
BLK-11	Free/paid, скидка 40% на первый месяц; цена и квоты ожидаются	accepted + pending
BLK-12	подписка и консультация — разные продукты/payment flows	accepted + pre-pilot
BLK-13	passwordless e-mail OTP через Resend; Telegram исключён	accepted
BLK-14	минимальная защита internal, полный legal/privacy gate перед пилотом	accepted + pre-pilot
BLK-15	потребность в админ-панели подтверждена; текущий MVP/договор уточняется	pending
BLK-16	каталог, заявка, ручное согласование, статус и оплата; без chat/video/calendar	accepted

План от 04.09.2026 (исторический, см. актуализацию выше)

1. Все рекомендуемые defaults из исходной версии реестра становятся решениями для проектирования и разработки.
2. Методики numerology-pythagorean-v0, human-design-standard-v0 и destiny-matrix-22-v0 изолируются за единым интерфейсом calculation engine и независимыми feature flags. Версия методики хранится вместе с каждым результатом; новую реализацию можно подключить без перезаписи старых данных. Заказчик отдельно подтверждает, какие движки входят в первый MVP; natal-only release остаётся допустимым вариантом.
3. Для закрытого коммерческого запуска выбрано направление Swiss Ephemeris Professional License. До покупки продолжаются только internal/test; лицензия, dataset manifest и экспертная/правовая проверка provisional-методик остаются обязательным pre-pilot gate.
4. AI-провайдер и модель не входят в доменную схему. Домен видит только AiProvider; provider/model/prompt snapshot записываются как метаданные конкретной генерации. Для сравнительных тестов используется OpenRouter, а production provider/model выбирается позднее по единому eval set.
5. Billing model сразу поддерживает Product и несколько immutable Price. Продуктовый baseline — бесплатный лид-магнит и один основной месячный paid tier; цена, квоты, скидки и entitlement задаются данными после утверждения, а не hardcode.
6. Auth — passwordless OTP на e-mail через Resend с серверной сессией/rotating refresh token. Telegram bot, Telegram linking и Telegram notifications исключены из MVP.
7. На внутренних тестах используем синтетические либо контролируемые тестовые данные и минимальный security baseline. Полный legal/privacy checklist обязателен до привлечения внешних пользователей.
8. Потребность в админ-панели зафиксирована, но её включение в текущий MVP/договор заказчик сверяет с Кириллом. До письменного изменения scope не создаются admin UI, /admin API или административный CRUD; telemetry и эксплуатационные инструменты остаются в baseline.

BLK-01 — единый источник продуктового scope

Проблема. prd.md описывает Karmnez как маркетплейс астрологов/тарологов, исключает собственный backend и AI, но включает расписание, бронирование, чат, видео и split. tz.docx описывает KarmaCode с четырьмя системами, подпиской, AI-разбором и более простым потоком консультаций. Последнее решение сохраняет backend и AI, но исключает админку.

Что заблокировано. Нельзя достоверно оценить MVP, окончательно разбить консультации на таблицы/endpoints и решить, нужны ли chat/video/calendar integrations в первом релизе.

Нужно решить:

1. официальное название и идентификатор продукта: KarmaCode или Karmnez;
2. считать ли tz.docx + текущую постановку главным baseline;
3. консультации P0 — только каталог, заявка, статус и оплата либо также календарь, закрытый чат и видео;
4. нужен ли дневник запросов из PRD отдельно от трекера целей или это один модуль с типами записи;
5. прогноз создаёт система, практик или оба источника с разными типами.

Рекомендуемый default исходного анализа. Baseline — KarmaCode из ТЗ; в P0 оставить четыре расчёта, подписку, AI, цели, каталог, заявку и разовую оплату. Calendar/chat/video и прогноз практика перенести в P1 до подтверждения экономики.

Принято с уточнением 04.09.2026. Название backend и методик — KarmaCode; переименование бренда позже не должно менять технические identifiers. Backend, AI, подписка и ограниченный consultation flow остаются в scope. Заказчик отдельно подтверждает, входят ли в первый MVP все четыре расчёта или только натальная карта, а также входит ли админ-панель в текущий договор.

Критерий закрытия. Владелец продукта письменно утверждает одну страницу scope с in/out/pending, названиями акторов и одним сквозным сценарием. Документ scope обновлён и явно показывает два pending решения; BLK-01 полностью закрывается после их перевода в in или out.

BLK-02 — неизвестное или неточное время рождения

Проблема. ТЗ блокирует астрологию и Human Design без точного времени. PRD предлагает «утро/день/вечер». ASC и дома чувствительны к минутам, а Луна/другие точки могут сменить знак или конфигурацию в течение выбранного диапазона.

Что заблокировано. Поля timeAccuracy, состояния частичного расчёта, тексты paywall/ректификации и правила выдачи AI-интерпретации.

Варианты решения:

• strict: считать только нумерологию и Матрицу, остальные показывать locked;
• date-only: выдавать только положения, устойчивые на всём суточном интервале, без ASC/MC/домов/HD;
• approximate: пользователь выбирает период, система считает условную точку и явно маркирует ненадёжные элементы.

Рекомендуемый default. strict для MVP. Он соответствует более конкретному ТЗ и не создаёт ложную точность.

Принято. В схеме остаются exact/unknown; приблизительных периодов в MVP нет.

Критерий закрытия. Решение утверждено продуктом и астрологом; есть API-примеры для exact/unknown, UX-текст, правило entitlement и тест, доказывающий отсутствие скрытого расчёта домов при unknown.

BLK-03 — параметры астрологической методики

Проблема. Swiss Ephemeris возвращает астрономические координаты, но не выбирает за продукт zodiac, систему домов, набор объектов и орбисы. Фраза на скриншоте «орбис обычно ±6–10°» не является однозначной таблицей. Без одинаковых настроек сравнение с Astro-Seek бессмысленно.

Что заблокировано. natal-v1, golden fixtures, совпадение результатов между окружениями и тексты бесплатных фактов.

Нужно утвердить:

• tropical или sidereal zodiac, geocentric или topocentric positions;
• десять тел из скриншота либо дополнительные узлы/Лилит/Хирон;
• Placidus как default и поведение на широтах, где он не определяется;
• аспекты и точные орбисы, бонусы светил, границы <= либо <, applying/separating;
• календарь для исторических дат, допустимый диапазон дат и точность отображения;
• три эталонных кейса и полные настройки Astro-Seek для каждого.

Рекомендуемый default. Настройки natal-v1 из алгоритма: tropical, geocentric, Sun/Moon + 8 планет, Placidus, пять мажорных аспектов, орбисы 8° для conjunction/opposition и 6° для остальных; при недоступном Placidus — явная ошибка, без silent fallback.

Принято. Любое изменение этих параметров создаёт новую версию алгоритма.

Критерий закрытия. Подписанная карточка методики, versioned orb table и три сохранённых fixtures; все долготы расходятся с согласованным эталоном менее чем на 0,5°.

BLK-04 — лицензия и набор данных Swiss Ephemeris

Проблема. Swiss Ephemeris имеет двойную модель: AGPL либо Professional License. Метаданные npm-wrapper не отменяют лицензию встроенного core. В репозитории пока нет утверждённого набора .se1-файлов и manifest.

Что заблокировано. Публичный сервис, production image, распространение закрытого кода вместе с движком и окончательная supply-chain политика.

Нужно решить:

1. открыть совместимый проект под AGPL или приобрести Professional License;
2. кто хранит договор/notices и контролирует срок/условия лицензии;
3. какой диапазон ephemeris-файлов нужен для допустимых дат рождения и прогнозов;
4. можно ли включать файлы в Docker image/registry и кто имеет к нему доступ.

Рекомендуемый default. Для закрытого коммерческого сервиса запросить Professional License до начала публичного пилота. До решения использовать binding только во внутреннем spike.

Принято для разработки. Внутренние тесты продолжаются на текущем binding. По итогам звонка 04.09.2026 для закрытого коммерческого продукта выбрано направление Professional License; 700 CHF — только озвученный ориентир. Проверка актуальных условий, покупка лицензии и dataset manifest — обязательные пункты pre-pilot checklist, без которых внешний пилот не запускается.

Критерий закрытия. Есть подписанный license decision и необходимые notices; в ephemeris лежит утверждённый manifest с версиями/SHA-256, CI проверяет файлы, а production запрещает fallback с SEFLG_SWIEPH.

BLK-05 — геокодирование и историческая таймзона

Проблема. Название города не содержит координаты и исторический UTC offset. Текущий offset города нельзя применять к дате рождения: правила зон и DST менялись. Провайдер геокодирования/таймзон не выбран.

Что заблокировано. Точная конвертация local time → UTC, а значит ASC, MC и дома; также договорные условия хранения ответов геопровайдера.

Нужно решить: provider поиска мест, источник IANA timezone ID, версия tzdata, язык/страны поиска, поведение для переименованных городов, ambiguous/nonexistent local time и ручной ввод координат.

Рекомендуемый default. Provider adapter; сохранять immutable snapshot label/lat/lon/timezoneId/providerVersion, а offset вычислять по закреплённой tzdata. Не хранить только строку города или только offset.

Принято. Конкретный геопровайдер заменяем и не влияет на доменную схему.

Критерий закрытия. Подтверждены provider/terms/cost; есть fixtures обычной даты, исторической смены зоны, осенней неоднозначности и несуществующего весеннего времени.

Уточнение scope от 04.09.2026 для BLK-06…BLK-08. Целевой продукт сводит доступные расчётные системы в единый отчёт из одного окна ввода. Заказчик допустил natal-only MVP, но ещё не утвердил состав первого релиза и источники методик трёх остальных систем. До решения контракты остаются заменяемыми и независимо выключаемыми; их публикация невозможна без описания входов, алгоритма, выхода, эталонных примеров и прав.

BLK-06 — методика нумерологии

Проблема. Названия «число судьбы», «жизненного пути» и «личности» используются разными школами для разных формул. Не заданы таблица кириллицы, роль имени, редукция и master numbers.

Что заблокировано. Input schema имени, движок, бесплатные подписи, fixtures и evidence mapping.

Нужно решить: школа/автор; формула каждого числа; имя при рождении или текущее ФИО; кириллица/латиница/ё/дефисы; 11/22/33; промежуточные суммы и граничные примеры.

Принятое временное решение. Реализовать numerology-pythagorean-v0, полностью описанную в документе расчётов. Движок подключается через заменяемый port; экспертная сверка и решение о сохранении/замене методики вынесены в pre-pilot.

Критерий закрытия. Выполнен Definition of Ready из описания движков, эксперт подписал JSON fixtures и mapping бесплатных facts.

BLK-07 — полная методика и права Human Design

Проблема. Указание «88° солнечной дуги» определяет только design date. Оно не задаёт разметку 64 ворот/6 линий, planetary activations, каналы, центры, type, authority и profile. Не проверены права коммерческого использования таблиц и терминологии.

Что заблокировано. Весь результат Human Design и законная публикация его трактовок.

Нужно решить: источник/лицензия таблиц; точная gate wheel; тела/узлы; алгоритмы channels/centers/type/strategy/ authority/profile; точность root finding design date; поведение на границах gate/line.

Принятое временное решение. human-design-standard-v0: design date ищется по дуге 88°, а gate/channel tables хранятся как versioned resources за заменяемым engine port. Экспертная и правовая проверка обязательна pre-pilot.

Критерий закрытия. Юрист подтвердил права, эксперт утвердил полную versioned методику и минимум десять fixtures, включая границы ворот/линий.

BLK-08 — школа и права Матрицы судьбы

Проблема. Под одним названием существуют разные схемы позиций, нумерация арканов и правила сведения сумм.

Что заблокировано. Формула, JSON positions, интерпретация и cross-system evidence.

Нужно решить: конкретная школа/автор; схема позиций; диапазон арканов; обработка 0/22; промежуточные суммы; названия/семантика позиций и коммерческие права.

Принятое временное решение. Использовать собственную однозначную схему destiny-matrix-22-v0 из документа расчётов, не приписывая её конкретной школе. Перед пилотом эксперт либо утверждает её, либо подключается новая версия движка.

Критерий закрытия. Право использования подтверждено, есть формула, диаграмма позиций и экспертные fixtures по Definition of Ready.

BLK-09 — экспертная карта фактов на оси интерпретации

Проблема. Оси axes-v1 приняты как стартовый контракт, но экспертные словари factId, веса, совместимость и правила противоречий пока существуют только как versioned v0 data. Без явных таблиц AI будет заново изобретать структуру для каждого пользователя — именно это запрещает ТЗ.

Что заблокировано. Воспроизводимый AI input, confidence, meaningful tensions, бесплатные factual labels и экспертная оценка качества.

Нужно решить: финальный набор осей; facts каждой системы; fact → axis; независимость подтверждений; compatibility/ tension matrix; веса/confidence rules; safe practices; consultation triggers.

Рекомендуемый default. Начать с axes-v1, но не позволять модели назначать mappings/weights. Всё хранится в versioned экспертных таблицах.

Принято. Оси и mappings являются входными данными AI, а не результатом его свободного рассуждения.

Критерий закрытия. Эксперты четырёх систем подписали mapping; тестовый evidence builder детерминированно выдаёт одинаковую matrix; каждый ожидаемый тезис связан с существующим factId.

BLK-10 — AI provider, privacy и правила публикации

Проблема. Не выбраны provider/model, регион обработки, политика хранения/обучения, лимиты стоимости и disclosure. Не определено, публиковать ли первую генерацию автоматически или после review.

Что заблокировано. SDK/adapter, договор по данным, production prompt, бюджет, safety SLA и release AI-функции.

Нужно решить:

• provider/model snapshot и structured-output возможности;
• можно ли передавать birth data/цели за пределы выбранного контура и какие поля псевдонимизируются;
• retention/no-training/DPA и удаление provider-side данных;
• max tokens/cost/user quotas, timeout/retry и fallback;
• human review первой когорты, жалобы и регенерация;
• честная пользовательская формулировка об автоматическом анализе без маркетингового акцента на AI;
• prohibited claims, особенно для здоровья, финансов и категоричных предсказаний.

Рекомендуемый default. Provider-neutral adapter, двухшаговый evidence → narrative, без имени/e-mail/адреса, строгий JSON Schema, ручное review первой production-выборки и hard safety gates.

Принято. Конкретная модель не фиксируется в домене или публичном API. provider, modelSnapshot, версии prompt и policy сохраняются на каждой генерации; смена модели не требует миграции расчётов. Для тестового сравнения нескольких моделей выбран OpenRouter; заказчик предоставляет пополненный token через защищённый канал. Выбор OpenRouter для eval не является автоматическим выбором production provider.

Критерий закрытия. Подписан data-flow/DPA decision, зафиксированы model/prompt/policy versions и бюджет; eval-набор проходит hard gates из AI-документа, есть kill switch и сценарий provider outage.

BLK-11 — коммерческие правила подписки

Проблема. ТЗ говорит «подписка», но не задаёт тарифы и state machine. Цена влияет не только на UI, но и на immutable Price, invoice periods, entitlement, возвраты, чеки и аналитику LTV.

Что заблокировано. Физическая billing schema, renewal worker, paywall contract и большинство edge cases.

Нужно решить: цена/валюта/период; момент начала; trial; grace period; retry schedule; cancel immediately или at period end; refund policy; смена цены; доступ после failed renewal/refund; квоты AI/прогнозов; входит ли tracker только в paid tier.

Принято. Модель данных сразу поддерживает несколько продуктов и immutable цен. Продукт имеет бесплатный лид-магнит и один основной месячный RUB-тариф; консультации оплачиваются отдельно. Около 800 ₽, скидка 30–40% на первый месяц, одна–три бесплатные попытки и годовой тариф остаются гипотезами. Точная сумма, trial/discount, квоты, cancel-at-period-end и остальные правила задаются seed/config data только после entitlement decision, а не hardcode.

Критерий закрытия. Есть таблица состояний/переходов и примеры для initial payment, renewal, past_due, cancel, expire и refund; оферта и backend policy используют одну версию правил.

BLK-12 — договорная схема YooKassa и практиков

Проблема. Подписку можно принимать как собственную услугу платформы, но консультация имеет второго получателя. Обычный платёж, Split payments, «Безопасная сделка» и модель «платформа — продавец» юридически и технически различны. Для split платформа и продавцы должны быть подключены по соответствующей программе YooKassa.

Что заблокировано. Production shop, чеки по 54-ФЗ, transfers/settlements, точный размер комиссии, возврат комиссии и выплата практику.

Нужно решить: кто является продавцом в чеке/оферте; статусы практиков; exact commission (PRD даёт диапазон 15–20%); нужен ли hold до оказания; split или safe deal; fiscal receipt provider; частичные возвраты; payout schedule; кто несёт provider fee/bonus при отмене.

Рекомендуемый default. Отдельно подключить обычные платежи/автоплатежи для подписки. Для консультаций получить у YooKassa и юриста письменное подтверждение выбранной marketplace-схемы; не имитировать split внутренней колонкой.

Принято. Внутренне проектируем два payment flow и общий provider port; production onboarding YooKassa, фискализация и marketplace-схема остаются pre-pilot gate. Оплата подписки предполагается на ИП заказчика, а production shop подключается после готовности сайта, тарифов и обязательных legal pages.

Критерий закрытия. Юрлицо и test shop готовы, автоплатежи включены, webhook HTTPS согласован, fiscal items утверждены; для консультаций есть договорная схема, seller onboarding и sandbox fixtures payment/refund/settlement.

BLK-13 — auth и каналы доставки

Проблема. E-mail должен собираться до paywall, но не выбраны password/OTP/magic-link flow, e-mail provider и Telegram linking. От этого зависят таблицы identity/session/token и шаблоны consent.

Что заблокировано. Финальный auth API, rate limits, recovery и уведомления.

Нужно решить: password или passwordless; обязательность verify до просмотра/оплаты; session transport; TTL и anti-abuse; e-mail provider/domain; Telegram bot ownership; темы opt-in/transactional сообщений.

Принято. Passwordless OTP на e-mail через Resend: 6 цифр, TTL 10 минут, повторная отправка не чаще 60 секунд, максимум 5 попыток, hash/HMAC кода в БД и rate limit по e-mail/IP. После проверки создаётся короткий access token и rotating HttpOnly refresh session. Telegram целиком исключён из MVP.

Критерий закрытия. Threat model, sequence diagrams и provider accounts готовы; тестируются enumeration, replay, rotation, revoke, rate limit и недоставленное письмо.

BLK-14 — ПДн, сроки хранения и обязательные документы

Проблема. Дата/место рождения, цели, консультационные заметки и документы практиков являются чувствительными данными продукта. ТЗ требует 152-ФЗ, оферту и дисклеймер, но тексты, роли обработки и retention не определены.

Что заблокировано. Публичный запуск, consent schema, data export/deletion, backups, AI data flow и права admin.

Нужно решить: состав/цели ПДн; основание обработки; локализация и трансграничная передача; consent versions; retention по типам; удаление против обязательного финансового хранения; processor contracts; доступ поддержки; дисклеймер и prohibited claims.

Рекомендуемый default. Data inventory + retention matrix до миграций с контентом; минимизация данных, отдельный защищённый storage документов, псевдонимизация AI input и policy-aware anonymization вместо безусловного cascade.

Принято с фазированием. Для internal используются синтетические/контролируемые данные, redacted logs, secrets вне репозитория и ограниченный доступ. Детальная юридическая проработка, документы и retention matrix обязательны перед внешним пилотом, но не блокируют внутреннее проектирование. Заказчик готовит юридический пакет для своего ИП и передаёт версии документов команде для публикации и технической привязки consent/policy versions.

Критерий закрытия. Ответственный юрист утвердил документы и data map; export/delete/backup/incident процессы имеют проверяемые правила и владельцев. Этот документ не заменяет юридическое заключение.

BLK-15 — административные полномочия и операционные процессы

Проблема. «Один экран админки» не определяет, кто может видеть документы/ПДн, возвращать деньги, публиковать AI или блокировать практика. Не определены двухэтапное согласование и retention audit log.

Что заблокировано. Финальный RBAC, admin action endpoints и безопасная операционная приёмка.

Нужно решить: реальные роли операторов; permissions matrix; MFA/session policy; какие действия требуют второго подтверждения; обязательный reason; кто обрабатывает disputes/safety complaints/dead jobs; сроки audit/export.

Статус переоткрыт 04.09.2026. Заказчик считает админ-панель необходимой для просмотра состояния и управления, но уточняет у Кирилла, была ли она включена в договор и текущий объём работ. До письменного ответа действует консервативный engineering baseline: не создаём admin role, /admin endpoints, административные repositories/services или UI; сохраняем доменные события, логи и технические метрики. Возможный состав модуля описан в отдельном документе и попадёт в MVP только вместе с утверждёнными ролями, операциями, аудитом, критериями приёмки и обновлённой оценкой.

BLK-16 — консультационный workflow и edge cases

Проблема. PRD содержит booking/chat/video/no-show/anti-bypass, а ТЗ — только каталог/заявку/статус. Не определены точные состояния, момент списания/выплаты, видимость натальной карты и заметок.

Что заблокировано. Consultation schema/state machine, доступ практика к данным клиента и marketplace payment flow.

Нужно решить: P0 features; request→accept→schedule→pay порядок; reschedule/cancel/no-show windows; dispute 48h; когда консультация считается оказанной; public/private notes; срок доступа к карте; video provider; chat moderation и что считается bypass; санкции после отмен/нарушений.

Рекомендуемый default. В P0 оставить каталог, заявку, ручное согласование времени, статусы и оплату; не хранить чат и видео до отдельного решения. Доступ практика к карте — только для активной консультации и с аудитом.

Принято. Chat, video, calendar integration и автоматическая moderation не входят в MVP.

Критерий закрытия. Утверждены state diagram, policy version и role/visibility matrix; sandbox E2E покрывает успех, отказ, отмену практика, no-show, спор, refund и settlement.

Порядок закрытия

1. Проектирование БД: продолжается по текущему backend baseline; pending-решения не расширяют схему до письменного утверждения.
2. Внутренняя разработка: допускает provisional engines и sandbox providers с version metadata.
3. До внешнего пилота: выполнить все пункты pre-pilot checklist.
4. Админ-панель: после ответа заказчика либо остаётся отдельным post-MVP module, либо получает собственное согласованное расширение scope/архитектуры/оценки до реализации.

Как фиксировать закрытие

Для каждого ID создаётся короткий ADR/decision record:

Blocker ID:
Decision:
Chosen option and rejected alternatives:
Owner/approvers:
Effective date:
Affected schemas/APIs/policies:
Fixtures or legal/provider evidence:
Next review date, if any:

После решения меняются статус в сводке, связанные документы и acceptance tests. Сообщение в чате без обновления versioned документа не считается закрытием блокера.