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

Статус на 2026-09-03: план разрешения принят. Архитектурных блокеров для следующего этапа — проектирования БД — нет. Часть решений принята как временная методика v0; она реализуется через заменяемые модули и обязательно проверяется по pre-pilot checklist перед внешним пилотом.

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

Уровни¶

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

Сводка¶

ID	Принятое направление	Состояние
BLK-01	KarmaCode/TЗ как baseline; консультации без chat/video/calendar	accepted
BLK-02	без точного времени астрология и Human Design заблокированы	accepted
BLK-03	методика `natal-v1` из документа расчёта	accepted
BLK-04	Swiss Ephemeris используется для internal; лицензия обязательна до пилота	accepted + pre-pilot
BLK-05	provider adapter + immutable place/timezone snapshot	accepted
BLK-06	собственная минимальная методика `numerology-pythagorean-v0`	provisional/pre-pilot
BLK-07	`human-design-standard-v0` в заменяемом модуле	provisional/pre-pilot
BLK-08	собственная детерминированная схема `destiny-matrix-22-v0`	provisional/pre-pilot
BLK-09	оси и evidence mapping версионируются и не определяются моделью	accepted
BLK-10	AI только через provider-agnostic port; модель — runtime configuration	accepted
BLK-11	каталог поддерживает много тарифов, в пилоте активен один	accepted
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	admin UI и admin API полностью исключены из MVP	excluded
BLK-16	каталог, заявка, ручное согласование, статус и оплата; без chat/video/calendar	accepted

Принятый план¶

Все рекомендуемые defaults из исходной версии реестра становятся решениями для проектирования и разработки.
Методики numerology-pythagorean-v0, human-design-standard-v0 и destiny-matrix-22-v0 изолируются за единым интерфейсом calculation engine. Версия методики хранится вместе с каждым результатом; новую реализацию можно подключить без перезаписи старых данных.
Лицензия Swiss Ephemeris и экспертная/правовая проверка трёх provisional-методик перенесены в обязательный pre-pilot gate, но не блокируют внутреннюю разработку.
AI-провайдер и модель не входят в доменную схему. Домен видит только AiProvider; provider/model/prompt snapshot записываются как метаданные конкретной генерации.
Billing model сразу поддерживает Product и несколько immutable Price, но при запуске создаётся один активный месячный тариф. Его сумма задаётся данными, а не кодом.
Auth — passwordless OTP на e-mail через Resend с серверной сессией/rotating refresh token. Telegram bot, Telegram linking и Telegram notifications исключены из MVP.
На внутренних тестах используем синтетические либо контролируемые тестовые данные и минимальный security baseline. Полный legal/privacy checklist обязателен до привлечения внешних пользователей.
Админ-панель целиком исключена: в MVP нет ни admin UI, ни /admin API. Сбор аналитических/операционных событий остаётся, а отдельный admin module проектируется после MVP.

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

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

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

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

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

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

Принято. Этот default становится scope MVP. Название backend и методик — KarmaCode; переименование бренда позже не должно менять технические identifiers.

Критерий закрытия. Владелец продукта утверждает одну страницу scope с in/out/pending, названиями акторов и одним сквозным сценарием. Документ scope обновлён без пометок о противоречии.

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 политика.

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

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

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

Принято для разработки. Внутренние тесты продолжаются на текущем binding. Покупка/выбор лицензии и 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 обычной даты, исторической смены зоны, осенней неоднозначности и несуществующего весеннего времени.

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 сохраняются на каждой генерации; смена модели не требует миграции расчётов.

Критерий закрытия. Подписан 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-тариф без trial, cancel-at-period-end; сумма и остальные коммерческие параметры задаются seed/config data, а не 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.

Критерий закрытия. Юрлицо и 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 обязательны перед внешним пилотом, но не блокируют внутреннее проектирование.

Критерий закрытия. Ответственный юрист утвердил документы и 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.

Принято — исключить из MVP. Не создаём admin role, /admin endpoints, административные repositories/services или UI. Сохраняем только доменные события, логи и технические метрики, чтобы будущий модуль мог их читать. Предварительный scope перенесён в post-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.

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

Проектирование БД: начинается со всех принятых решений этого документа; открытого blocker нет.
Внутренняя разработка: допускает provisional engines и sandbox providers с version metadata.
До внешнего пилота: выполнить все пункты pre-pilot checklist.
После MVP: отдельно спроектировать admin module, не расширяя сейчас MVP schema/API административным CRUD.

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

Для каждого 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 документа не считается закрытием блокера.