---
document: Техническое задание NAP Store
version: 1.1
status: черновик
date: 2026-10-31
supersedes: 1.0
based_on: NAP-060 (закрепить решения MVP); NAP-041, NAP-052, NAP-065, NAP-067, NAP-068, NAP-069, NAP-079, NAP-080, NAP-082, NAP-003, NAP-005, NAP-006, NAP-007
implemented_by: NAP Store 0.3.0 — 0.4.x (реализовано до утверждения; черновик закрепляет принятые решения)
---
# Техническое задание: NAP Store — приложения, бинауральный конвертер и магазин оборудования
Ты — ведущий full-stack разработчик проекта NAP Store. Создай работающую платформу по этому техническому заданию.
Нужен полноценный продукт: интерфейс на русском и английском языках, сервер, база данных, настоящий аудиоконвертер, магазин приложений, магазин оборудования, платежи, подписки, кабинеты разработчиков и поставщиков, международная доставка, SDK/API и интеграция с нейроакустическим креслом NAP SYSTEM.
Не ограничивайся планом, дизайном или статическими демонстрационными экранами. Реализуй работающие пользовательские сценарии, сохранение данных и проверяемую бизнес-логику.
Начни с изучения репозитория и его инструкций. Если проекта ещё нет, создай структуру. Обычные инженерные решения принимай самостоятельно, существенные допущения записывай в документацию. Работай поэтапно, проверяй результат и продолжай реализацию.
Отсутствие платёжных ключей, документации кресла или аккаунта перевозчика не должно останавливать разработку всей платформы. Для таких систем реализуй документированные адаптеры и явно обозначенные демонстрационные режимы. Сам аудиоконвертер должен действительно обрабатывать загруженные файлы.
## Изменения относительно версии 1.0
Черновик v1.1 закрепляет решения, принятые и реализованные с 31.10.2026 в рамках существующих областей ТЗ. Новые области и смена денежной модели (режим 5.1, кошелёк и модели оплаты, мобильные приложения, токен) в v1.1 не входят — они перечислены в разделе 21 как кандидаты в ТЗ 2.0.
| Раздел | Изменение | Задача бэклога |
|---|---|---|
| 5 | Редактор приложения: баннер «Следующий шаг», чек-лист готовности, сообщения о результате действий, подсказка о несохранённых изменениях; модератор видит подтверждение решения и следующую версию в очереди | NAP-082 |
| 5 | Шапка на телефоне — одна строка с меню, доступным с клавиатуры; без горизонтальной прокрутки страниц на ширине 390 px | NAP-041, NAP-081 |
| 5 | Корзина блокирует оформление, если позиции нет в нужном количестве, с понятной причиной; позицию можно убрать | NAP-081 |
| 5, 6 | Проверка полей формы в браузере совпадает с сервером; ошибка называет поле на языке интерфейса | NAP-067, NAP-068 |
| 8 | Загрузка файлов частями по 8 МБ с докачкой; контрольная сумма считается в браузере по частям | NAP-069 |
| 8 | Конвертация стартует сразу после загрузки (отключаемо); первый готовый трек становится сеансом 1 пустой программы | NAP-069 |
| 8 | Профиль «Гамма (40 Гц)»: 200/240 Гц, чистые синусоиды, строгое стерео (ожидает подписи методистов) | NAP-080, NAP-061 |
| 16, 17 | Ограничение частоты запросов, ответ 429 с локализованным текстом и Retry-After | NAP-052 |
| 17 | Доставка писем (log/file/SMTP) с повтором и экспоненциальной паузой | NAP-007 |
| 17 | Ежедневный бэкап с автоматической проверкой восстановления; мониторинг и оповещения | NAP-006, NAP-005 |
| 17 | CI на каждый коммит, обязательная проверка перед слиянием | NAP-003 |
| 20 (новый) | Оценки и отзывы приложений и товаров | NAP-065, NAP-079 |
| 18 | Критерии приёмки 39–52 | — |
## 1. Идея и назначение платформы
NAP Store — маркетплейс по модели App Store для нейроакустической платформы NAP SYSTEM.
Авторы аудиокниг, медитаций, музыки и образовательных программ могут:
- зарегистрироваться;
- загрузить свой аудиоконтент;
- подготовить его с помощью бинаурального конвертера;
- создать приложение или программу сеансов;
- опубликовать её в Store;
- продавать доступ или подписку;
- получать доход.
Пользователи могут:
- находить и приобретать приложения;
- запускать программы на совместимом оборудовании;
- проходить оценку состояния до и после сеанса;
- покупать кресла, акустику, наушники и другие необходимые устройства;
- собирать подходящий комплект;
- оформлять заказ прямо в Store;
- получать оборудование через международную доставку.
Разработчикам также предоставляются SDK и API для подключения собственных приложений и сервисов.
Согласованная комиссия по цифровым приложениям и подпискам: **30% платформе, 70% разработчику**.
Для физических устройств применяется отдельная коммерческая политика. Не распространяй автоматически распределение 30/70 на продажу кресел, наушников и другого оборудования.
## 2. Что считается приложением
В первом релизе приложение — декларативный пакет, содержащий:
- название, описание, автора, категорию и обложку;
- один или несколько аудиотреков;
- последовательность занятий или сеансов;
- длительность и параметры воспроизведения;
- профиль бинаурального слоя;
- требования к оборудованию;
- анкеты до и после;
- сведения о версии и контрольные суммы файлов.
Это может быть отдельная медитация, библиотека аудиокниг, курс или программа из нескольких занятий.
Пакет выполняется доверенным проигрывателем платформы. Произвольный сторонний JavaScript, Python, нативные модули и команды оборудования внутри загружаемого пакета в MVP не исполняются.
Внешние приложения подключаются через SDK/API. Расширяемая среда исполнения стороннего кода — отдельный последующий этап.
## 3. Исследовательская и методическая база
При проектировании изучить опубликованные подходы:
- Института Монро — бинауральные биения, многослойные композиции, изменение звуковых параметров на протяжении сеанса, историческое развитие Hemi-Sync и Monroe Sound Science: https://www.monroeinstitute.org/pages/the-history-of-sound-at-the-monroe-institute
- Джеффри Д. Томпсона / Center for Neuroacoustic Research — нейроакустические композиции, описываемые автором фазово-модулированные бинауральные биения, пространственная обработка и сочетание аудио с виброакустикой: https://centerforneuroacousticresearch.com/webinars/
Это методические ориентиры для собственной реализации. Они не означают наличия лицензии, партнёрства, одобрения или доступа к закрытым алгоритмам этих организаций.
В MVP реализовать собственный проверяемый генератор двух несущих. Не заявлять воспроизведение закрытых авторских технологий.
Профиль «Альфа» должен создавать аудиостимул с заданной разницей частот, например 10 Гц. Техническая проверка подтверждает параметры сигнала. Достижение определённого состояния мозга проверяется отдельно и не гарантируется самим наличием таких частот в файле.
Не использовать в интерфейсе обещания гарантированного перехода в альфа-состояние или лечебного результата.
## 4. Роли и разграничение доступа
Реализовать роли:
1. Гость: опубликованный каталог, карточки, разрешённые превью.
2. Пользователь: покупки, подписки, библиотека, свои устройства, сеансы, измерения, аппаратные заказы и адреса.
3. Разработчик: собственные приложения, исходники, задания конвертации, версии, цены, аналитика, доходы и SDK-ключи.
4. Продавец/поставщик: собственные товары, комплекты, остатки, назначенные заказы, комплектация, отправления и возвраты.
5. Оператор исполнения: только назначенные заказы и данные, необходимые для упаковки и доставки.
6. Модератор: проверка материалов и версий, решения с комментариями.
7. Администратор: роли, настройки, категории, профили DSP, аудит и операции.
8. Сервис устройства: ограниченные права конкретного устройства и сеанса.
Один аккаунт может совмещать несколько ролей, но разрешения выдаются отдельно.
Проверять права на сервере для каждой операции. Разработчик не видит чужие исходники и финансовые данные. Поставщик не видит чужие заказы, аудиоматериалы и диагностические записи покупателей.
## 5. Интерфейсы и основные сценарии
### Кабинет разработчика
Сценарий:
Регистрация → приложение → загрузка аудио → профиль конвертации → обработка → прослушивание и QA-отчёт → программа сеансов → цена → модерация → публикация → продажи и начисления.
Обязательные возможности:
- черновики и версии;
- загрузка нескольких файлов с прогрессом;
- запуск, статус, отмена и повтор конвертации;
- сравнение исходника и результата;
- просмотр параметров обработки;
- конструктор программы из сеансов;
- настройка описания, обложки, категории и совместимости;
- подтверждение прав на контент;
- комментарии модератора;
- обновление через новую версию;
- продажи, подписки, возвраты, комиссия, начислено, доступно и выплачено;
- создание и отзыв ограниченных SDK-ключей.
### Покупатель приложений
Каталог → поиск → карточка → превью → покупка или подписка → библиотека → проверка оборудования → анкета до → сеанс → анкета после → история.
Реализовать каталог, фильтры, карточку приложения, библиотеку, историю покупок, управление подписками, подключение устройства, проигрыватель, анкеты и историю показателей.
В карточке показывать автора, программу, длительности, язык аудио, совместимость, цену, период и условия подписки.
### Покупатель оборудования
Раздел «Устройства» → карточка или подбор комплекта → корзина → международный адрес → доставка → оплата → комплектация поставщиком → отправление → tracking → получение или возврат.
Из карточки приложения предоставить переход «Подобрать оборудование».
### Поставщик
Получение подтверждённого заказа → комплектация → упаковочные места → документы → передача перевозчику → tracking → обработка проблем и возвратов.
### Администратор
Модерация приложений и товаров, проверка совместимости, управление продавцами, заказами, остатками, маршрутами, профилями DSP, возвратами и аудитом.
### Общие требования
Адаптивный интерфейс для компьютера, планшета и основных действий на телефоне. Спокойный современный дизайн Store, понятные карточки, обложки, цена и совместимость. Собственное оформление.
Нужны состояния загрузки, пустого списка, ошибки, повтора, недоступного устройства и незавершённой операции. Формы должны работать с клавиатуры. Сложные DSP-настройки убрать в расширенный режим.
### Дополнения v1.1 к разделу 5
- **Редактор приложения.** На всех вкладках — баннер «Следующий шаг» по состоянию версии: что заполнить (со ссылкой на вкладку), что версия готова к отправке, срок ожидания решения, что делать после одобрения (публикация, при отсутствии цены — сначала цена) или отклонения (комментарий модератора и создание новой версии), ссылка на витрину после публикации. На вкладке «Версии и публикация» — чек-лист: название, подтверждённые права, сеанс с треком (обязательно), цена (обязательна до публикации). Кнопка отправки активна, когда обязательное готово. После сохранения, отправки, публикации, отзыва версии, остановки и возобновления продаж — сообщение о результате. Несохранённые изменения на вкладке «Описание» обозначаются.
- **Модерация.** После решения — подтверждение («одобрено/отклонено, автор получил уведомление»), переход к следующей версии в очереди и к списку. Одобрение не публикует версию: публикует автор.
- **Формы.** Шаблоны полей в браузере совпадают с серверной проверкой и компилируются с флагом `v`; адрес приложения нормализуется при вводе (строчные латинские буквы, `_` и пробелы → `-`). Ошибка проверки на сервере называет поле(я) на языке интерфейса и подсвечивает их; внутренние ошибки (500) на некорректный ввод недопустимы — ответ 422 с полем.
- **Корзина.** Позиция, которой нет в нужном количестве, подсвечивается, оформление блокируется с перечислением таких позиций; у каждой позиции есть «Убрать».
- **Телефон.** На ширине 390 px шапка занимает одну строку; разделы и аккаунт — в меню (кнопка с `aria-expanded`, Esc закрывает и возвращает фокус, переход по ссылке закрывает меню). Ни одна страница не прокручивается горизонтально; широкие таблицы прокручиваются внутри себя.
## 6. Русский и английский языки
Оба языка входят в первый релиз: `ru` и `en`.
Полностью локализовать:
- оба каталога;
- конвертер и проигрыватель;
- кабинеты всех ролей;
- формы, ошибки, подсказки и статусы;
- корзины и оформление заказа;
- оплату, доставку и возвраты;
- системные письма и уведомления.
Публичные страницы доступны по `/ru/...` и `/en/...`. Реализовать правильные `lang`, заголовки, метаданные и `hreflang`.
Язык сохраняется в профиле и cookie. При первом визите учитывать язык браузера, резервный язык — русский.
Переключение сохраняет текущую карточку, авторизацию, корзины и безопасно сохраняемые данные формы. Оно не создаёт новый товар или заказ.
Строки интерфейса хранить в словарях с параметрами и формами множественного числа.
Для карточек, инструкций и условий поставки хранить отдельные переводы со статусами `missing / draft / published`. Контент платформы и demo-каталог должны иметь опубликованные RU/EN-версии. Внешний авторский текст без перевода можно показывать в оригинале с явной отметкой языка.
Язык интерфейса, описания, аудиозаписи и страна доставки — независимые параметры. Переключение языка не переводит и не заменяет аудио.
У товара и приложения общие ID, цена, остаток и права для обеих локалей. Локаль меняет форматирование чисел и дат, но не валюту и сумму заказа. Конвертация валют в MVP не входит.
Международные адреса поддерживают Unicode. Обязательные поля зависят от страны и перевозчика. Не навязывать российский формат индекса и обязательный регион всем странам. Латиницу требовать только при действительном требовании перевозчика.
Язык заказа сохраняется для уведомлений об оплате, отправке, проблеме и возврате. Машинные коды API и имена методов SDK от языка не меняются.
## 7. Рекомендуемая архитектура
Базовый стек:
- Frontend: Next.js App Router, React, TypeScript.
- Backend: Python, FastAPI, OpenAPI.
- База: PostgreSQL, миграции SQLAlchemy/Alembic либо сопоставимый слой.
- DSP: Python, NumPy, FFmpeg/ffprobe.
- Очередь: Celery и Redis.
- Файлы: закрытое S3-совместимое хранилище.
- SDK: TypeScript.
- Локальный запуск: Docker Compose.
Перед установкой проверить совместимые стабильные версии по официальной документации и зафиксировать зависимости и lock-файлы.
Бизнес-логика должна иметь одного владельца на backend. Не дублировать расчёты денег и доступа в Next.js и Python.
Конвертация выполняется worker, а не внутри HTTP-запроса. PostgreSQL хранит устойчивое состояние задания.
Разделить адаптеры:
- `PaymentProvider`;
- `ShippingAdapter`;
- `FulfillmentAdapter`;
- `DeviceAdapter`;
- адаптер измерений.
Секреты — только в окружении. Отдельные конфигурации demo, test и production. В production демонстрационные платежи и отправления недоступны.
## 8. Настоящий бинауральный аудиоконвертер
### Принцип
Сохранять исходную речь и музыку и добавлять отдельный бинауральный слой.
Левая несущая добавляется только в левый канал, правая — только в правый. Разница частот задаёт частоту биений.
Не сдвигать весь спектр аудиокниги на 10 Гц, не менять скорость и высоту речи. Генеративная AI-модель для базового алгоритма не требуется.
### Вход и выход
Принимать WAV, FLAC, MP3 и M4A с поддерживаемым кодеком. Реальный формат проверять декодером по содержимому.
Поддерживать моно и стерео. Файлы с числом каналов больше двух в MVP отклонять.
Проверять размер, длительность, наличие аудио, полное декодирование, повреждения и владельца.
Стартовые лимиты: до 1 GiB и до 120 минут. Они настраиваются сервером и показываются до загрузки.
Внутренний формат: 48 000 Гц, float32/float64, два канала. Моно дублировать в оба канала; стерео сохранять.
Основной мастер: WAV PCM 24 bit, 48 кГц, stereo. Формат доставки — WAV либо FLAC с подтверждённой поддержкой проигрывателя. Отдельное браузерное превью не заменяет мастер.
Сохранять содержание, длительность и число отсчётов после приведения исходника к 48 кГц.
### Формирование сигнала
Параметры:
`carrier_center_hz`, `beat_hz`, `source_gain_db`, `tone_gain_dbfs`, `fade_in_seconds`, `fade_out_seconds`, версия профиля и движка.
Формулы:
- `fL = carrier_center_hz − beat_hz / 2`
- `fR = carrier_center_hz + beat_hz / 2`
- `phaseL[n+1] = (phaseL[n] + 2πfL/Fs) mod 2π`
- `phaseR[n+1] = (phaseR[n] + 2πfR/Fs) mod 2π`
- `outL = sourceGain × sourceL + toneAmplitude × envelope × sin(phaseL)`
- `outR = sourceGain × sourceR + toneAmplitude × envelope × sin(phaseR)`
Для перевода dB в линейную амплитуду использовать `10^(dB/20)`.
`source_gain_db` означает изменение уровня исходника. `tone_gain_dbfs` — пиковый уровень каждого синуса до общего выходного gain.
Инженерный профиль `alpha-demo-v1`:
- центр 255 Гц;
- разница 10 Гц;
- 250 Гц слева, 260 Гц справа;
- исходник −6 dB;
- синус каждого канала −30 dBFS;
- плавное начало и завершение по 0,5 секунды.
Для коротких файлов края пропорционально сокращаются. Это настройки цифрового QA, не установленная терапевтическая доза.
В MVP частоты постоянны. При дальнейшем добавлении переходов интегрировать частоту в фазу; не использовать `sin(2π × f(t) × t)` вместо правильного интегрирования.
Фазовые аккумуляторы и приращения — float64 с modulo 2π либо эквивалентной точностью. Состояние сохраняется между блоками.
### Уровни и качество
Обрабатывать файл блоками, не загружать двухчасовой массив целиком.
Огибающая добавленного слоя начинается и заканчивается нулём.
Измерять итоговые LUFS и true peak. Потолок master: не выше −1 dBTP. Для соблюдения потолка допустимо уменьшить общий уровень одинаково для двух каналов.
Не применять скрытую компрессию, независимые лимитеры или независимую нормализацию каналов. Не усиливать автоматически до заданного LUFS.
Фактические уровни и общий gain сохранять в отчёте. Неизмеримые LUFS для тишины и коротких файлов обозначать `not_measurable`.
dBFS цифрового файла не считать громкостью у уха: калибровка относится к аппаратному тракту.
Автор выбирает разрешённый версионированный профиль. Собственный DSP-код и произвольные FFmpeg-фильтры из формы не принимать. Редактирование профиля создаёт новую версию.
### Результаты
Успешное задание создаёт:
- мастер;
- разрешённое превью;
- QA-отчёт;
- JSON с параметрами, характеристиками, SHA-256 входа и выхода, версиями профиля, движка и инструментов.
Для внутреннего QA можно сохранять отдельный бинауральный слой. Не публиковать его автоматически.
При одинаковых входных данных и фиксированной сборке декодированный PCM должен воспроизводиться.
### Очередь
Состояния:
`queued → validating → decoding → rendering → quality_check → packaging → completed`
Альтернативные конечные: `failed`, `canceled`.
Хранить владельца, этап, прогресс этапа, снимок профиля, попытку, временные метки и код ошибки. Обновлять интерфейс через SSE или polling.
Идемпотентный запрос не создаёт вторую задачу. Worker использует блокировку/lease. Временные ошибки допускают ограниченный retry, повреждённый файл автоматически не повторяется.
Отмена завершает дочерние процессы и удаляет временные данные. Гонка отмены и завершения разрешается транзакционно: ровно один конечный статус. Результат доступен только после QA и атомарного открытия полного набора файлов.
Повтор в MVP начинает обработку заново.
### Изоляция
FFmpeg запускать массивом аргументов без shell-интерполяции. Пользовательские имена не превращать в пути и параметры.
Для задания — отдельный временный каталог, ограничения CPU, памяти, диска и времени, отсутствие произвольного сетевого доступа.
Проверять место под декодированный WAV, а не только размер входного MP3. Серверное скачивание произвольных пользовательских URL не требуется.
### Дополнения v1.1 к разделу 8
- **Загрузка частями.** Браузер отправляет файл частями по 8 МБ (`PUT /api/v1/uploads/{token}` с `Content-Range: bytes a-b/total`) — так запросы проходят через прокси с ограничением тела. Части принимаются строго по порядку; при расхождении сервер отвечает 409 с текущим смещением, клиент продолжает с него; при 429 ждёт `Retry-After`. Один PUT без `Content-Range` остаётся допустимым (SDK). Контрольная сумма SHA-256 считается в браузере по частям, файл целиком в память не читается. Проверено на файле 60 минут.
- **Автоконвертация и программа.** После загрузки конвертация запускается сама с выбранным профилем (отключаемо). Первый успешно сконвертированный трек становится сеансом 1 пустой программы черновика с названием приложения; программа остаётся редактируемой. Задание конвертации не теряется при недоступном брокере очередей: остаётся в очереди и отправляется повторно.
- **Профиль «Гамма (40 Гц)»** (`gamma-40-v1`): чистые синусоиды 200 Гц (L) / 240 Гц (R), разница 40 Гц, каналы не смешиваются (подавление противоположной несущей ≥ 60 dB), тон −32 dBFS, плавный вход и выход 3 с; QA подтверждает 40 ± 0,1 Гц и true peak ≤ −1 dBTP. Требует наушников. Тексты — технические параметры без обещания состояния. Статус: реализован, ожидает подписи методистов (NAP-061); вариант слоя с амплитудной модуляцией 40 Гц — открытый вопрос.
## 9. Версии приложений и модерация
Состояния:
`draft → submitted → approved → published`
Дополнительные: `rejected`, `withdrawn`, `archived`.
После отправки фиксировать manifest, файлы, checksum и профиль. Существенная правка создаёт новый черновик и повторную модерацию. Нельзя подменить файл после одобрения.
Покупка связана с `app_id`; сеанс — с конкретной опубликованной совместимой версией и её аудиоартефактами.
Снятие с новых продаж не удаляет приложение автоматически из оплаченной библиотеки. Ограничение существующего доступа — отдельное аудируемое действие.
Manifest валидируется JSON Schema и содержит:
- версию схемы, app ID и версию приложения;
- автора, название, локализованные метаданные и язык контента;
- минимальную версию API устройства и требуемые capabilities;
- сеансы с ID, названием, asset ID, checksum, длительностью;
- профиль и версию DSP;
- требования доставки/воспроизведения;
- версии анкет до и после.
Цены и права доступа определяются сервером отдельно. Manifest не содержит исполняемых скриптов, произвольных команд оборудования или URL для серверного скачивания.
## 10. Покупки, подписки и распределение 30/70
Разделить заказ, попытку платежа, подписку, entitlement, финансовый журнал и выплату.
Успешный redirect в браузере не подтверждает оплату. Доступ выдаётся после серверного подтверждения.
Реализовать `PaymentProvider`:
- checkout;
- проверка и сверка операции;
- подписка и отмена автопродления;
- возврат;
- проверка webhook;
- нормализация событий.
Обязательны:
1. Рабочий `MockPaymentProvider`: успех, отказ, продление, возврат, дубли и перестановка событий, с явной маркировкой тестового режима.
2. Реализованный референсный адаптер Stripe Checkout/Billing в test-режиме. Для marketplace-выплат — Connect sandbox при наличии подключённых аккаунтов.
Выбор production-оператора, страны компании и валюты — конфигурация. Доступность Stripe для конкретной компании не предполагается. Другой оператор подключается через тот же контракт.
Без ключей работает mock. Live sandbox-тест без ключей отмечать `not run`, не выдавать его за пройденный.
Карточные реквизиты не хранить. Платёжные секреты не отправлять в браузер.
Webhook: проверить подпись на исходном теле, устойчиво сохранить уникальное событие и затем подтвердить приём. Обработку выполнять с повтором и дедупликацией. Учитывать конкурентную доставку и иной порядок событий.
Внешний API и БД не являются одной транзакцией: использовать inbox/outbox и reconciliation.
Подписки первой версии — на отдельное приложение. Создание подписки не равно оплате. Доступ предоставляется на подтверждённый оплаченный период. Отмена автопродления сохраняет доступ до `paid_until`; неуспешное продление не аннулирует уже оплаченный период. Grace period MVP — ноль, настраиваемый.
### Деньги
Суммы хранить целыми числами в минимальных единицах валюты, без float. Валюты не смешивать.
База цифрового распределения — подтверждённая стоимость контента без отдельно учтённого налога, за вычетом возвратов. В demo налог равен нулю.
30% платформе, 70% разработчику. Ставку сохранять снимком заказа. Комиссия оператора учитывается отдельно как расход платформы, без скрытого уменьшения доли автора.
Долю платформы округлять half-up, долю автора считать остатком.
Пример: 10 000 → 3 000/7 000. После возврата 4 000 остаток 6 000 → 1 800/4 200.
Для нескольких частичных возвратов пересчитывать целевые доли от накопленного остатка, чтобы округление не накапливало ошибку.
Финансовый журнал — неизменяемые сбалансированные проводки. Исправления только обратными/корректирующими записями. У каждой внешней операции уникальная бизнес-ссылка.
### Возвраты и выплаты
Полный возврат разовой цифровой покупки отзывает соответствующее право. Частичный возврат в MVP право сохраняет.
Возврат подписки относится к конкретному периоду и не удаляет другие оплаченные интервалы.
Различать начислено, ожидает, доступно и выплачено. Период удержания настраивается; для demo допустим ноль.
`paid` наступает после подтверждения провайдера. Mock-выплаты маркируются.
Возврат после выплаты создаёт корректировку/долг автора и учитывается в будущих выплатах. Отрицательные и заблокированные балансы отображаются.
## 11. Магазин оборудования и комплекты
Общая навигация:
- Приложения / Apps;
- Устройства / Devices;
- Комплекты / Kits.
Категории:
- кресла NAP SYSTEM;
- акустические и виброакустические комплекты;
- подходящие наушники;
- контроллеры и интерфейсы;
- датчики;
- блоки питания;
- кабели, переходники и другие компоненты.
Карточка содержит продавца, бренд/модель, фото, SKU/вариант, комплектацию, характеристики, цену/валюту, наличие или срок изготовления, гарантию, возвратные условия, страну отправления, доступные направления, срок подготовки, вес и габариты упаковки.
Показывать, входит ли сборка/установка.
Конкретные модели, цены и характеристики заполняются подтверждёнными данными поставщика.
### Совместимость
Хранить модели/API/firmware NAP SYSTEM, разъёмы, аудиоформаты, питание/вилку/напряжение, переходники, доступные функции и требования приложения.
Хранить статус подтверждения, источник, проверенную конфигурацию и дату. Отличать проверенную совместимость от заявления поставщика и непроверенного варианта.
Наличие стереодинамиков не доказывает разделение сигналов между ушами. Совместимость для виброакустики не равна подтверждённому бинауральному тракту.
### Комплект/BOM
Показывать обязательные и дополнительные позиции, количества, альтернативные совместимые SKU, питание и кабели.
Пользователь может отметить имеющееся оборудование. Система показывает недостающие компоненты для приложения/модуля и добавляет их в корзину.
Состав версионируется и сохраняется снимком заказа.
У собираемого комплекта наличие определяется компонентами, у готового складского — собственным SKU. Не списывать одновременно готовый комплект и его детали.
Рекомендуемое приложение может быть связано с комплектом, но цифровая лицензия не возникает автоматически без отдельно описанной покупки.
В MVP цифровая и аппаратная корзины/checkout раздельны. Физический заказ — один продавец, один склад отправления и одна валюта. Разные продавцы оформляются отдельными заказами; это видно до оплаты.
Многопродавцовый BOM не имеет общей атомарной покупки: показывать отдельные заказы и ещё не приобретённые компоненты.
## 12. Аппаратные заказы и склад
Использовать отдельный `HardwareOrder` и тип `hardware` в платёжном контексте. Оплата кресла не создаёт цифровой entitlement.
Сервер рассчитывает товары, доставку и отдельно учтённые сборы. Сохранять снимки SKU, количества, BOM, продавца, цен, адреса, локали, условий и тарифа.
Аппаратная выручка и расчёты с поставщиком имеют отдельную политику. Не начислять цифровому автору 70% стоимости устройства. В demo использовать явно обозначенную собственную продажу оператора.
Склад:
- `on_hand` — физически на складе;
- `reserved` — неоплаченный резерв с TTL;
- `allocated` — оплаченные неотгруженные позиции без TTL;
- `available = on_hand − reserved − allocated >= 0`.
Внутри одного заказа компоненты резервируются атомарно.
Оплата переносит `reserved → allocated`. Отгрузка одновременно уменьшает `on_hand` и `allocated`. Отмена освобождает соответствующее количество ровно один раз.
При поздней оплате после истечения резерва попытаться обеспечить остаток заново; иначе — явное исключение и предусмотренный возврат/согласование. Не подтверждать фиктивное наличие.
Производство под заказ имеет собственный срок и не показывается складским наличием.
Статусы заказа, платежа и исполнения независимы. Заказ может быть `awaiting_quote`, `awaiting_payment`, `confirmed`, `cancelled`, `closed`; исполнение — `unfulfilled`, `processing`, `partially_shipped`, `shipped`, `delivered`, `exception`.
Поставщик получает оплаченный подтверждённый заказ, комплектует, формирует упаковочные места и документы, передаёт перевозчику.
Один заказ может иметь несколько посылок. Каждая содержит свои позиции/количества, вес, габариты, документы и tracking. Нельзя отгрузить больше заказанного.
Отмена, денежный возврат и возврат товара — отдельные процессы. Реализовать запрос возврата, решение, обратную доставку, получение и проверку. Остаток увеличивается после фактической приёмки, не по нажатию кнопки.
Возвраты не превышают подтверждённую оплату. Доставка и сборы учитываются отдельными строками. Возврат оборудования не отзывает отдельно купленное приложение.
## 13. Международная доставка
До оплаты проверить адрес, склад отправления, доступность маршрута и услуги, ограничения груза, стоимость/валюту, срок действия тарифа и ориентировочную дату с учётом подготовки.
Тариф учитывает количество упаковочных мест, вес и габариты. Оценку срока не выдавать за гарантированную дату.
При неподдерживаемом маршруте, истёкшем тарифе или превышении габаритов не подставлять нулевую доставку.
Для крупногабаритного кресла поддержать индивидуальное предложение: запрос → расчёт поставщика → цена и срок действия → принятие покупателем → оплата.
Изменение адреса, состава или количества требует пересчёта до оплаты.
До оплаты показать товары, перевозку, упаковку/страхование при наличии и отдельно учтённые сборы. Плательщик импортных пошлин определяется условиями поставки. Неизвестные суммы не обозначать нулём или «всё включено».
Для международных документов хранить подтверждённые описание, количество, стоимость, валюту, страну происхождения, товарный код при необходимости и ограничения груза, включая батареи.
Упаковочный лист и данные инвойса формировать из снимка заказа. Не выдумывать HS-коды, ставки и разрешённые маршруты.
### Адаптеры
`ShippingAdapter`:
- доступные услуги;
- тарифы;
- создание/отмена отправления;
- документы;
- tracking;
- проверка и нормализация событий.
`FulfillmentAdapter`:
- передача заказа поставщику;
- подтверждение;
- комплектация;
- упаковочные места;
- передача перевозчику;
- ошибки.
Обязательны:
1. Рабочий `MockShippingAdapter` с воспроизводимыми тарифами и событиями.
2. Ручной режим: подтверждённый тариф/предложение поставщика, внешнее оформление отправки, загрузка документов и реального трека.
3. Реализованный референсный EasyPost test-адаптер по доступным сервисам.
Применимость EasyPost к любой стране или креслу не предполагается. Для неподдерживаемого груза использовать ручной freight-расчёт. Без ключей live-проверку отмечать `not run`.
Создание отправления идемпотентно: timeout не должен покупать вторую этикетку.
Tracking-события проверяются, сохраняются, дедуплицируются и сверяются при нарушении порядка. Хранить источник статуса: перевозчик, поставщик или симулятор.
История может включать создание этикетки, передачу, перевозку, таможню, доставку, исключение и возврат отправителю. Недоступные у перевозчика события не выдумывать.
Покупка этикетки не означает фактическую отправку или доставку. Общий статус заказа учитывает все посылки.
Международную перевозку выполняет поставщик через службу доставки. Платформа управляет заказом, документами и информацией об исполнении.
## 14. Кресло, проигрыватель и сеансы
Реализовать `DeviceAdapter`:
`connect`, `disconnect`, `getCapabilities`, `prepareSession`, `start`, `pause`, `resume`, `stop`, `getStatus`, события.
Capabilities содержат модель, firmware/API, sample rates, аудиовыходы, подтверждение разделения каналов, датчики, поддерживаемые функции и пределы параметров.
Рабочий `SimulatedDeviceAdapter` обязателен. Без документации производителя реальные команды кресла не выдумывать.
Сервер проверяет доступ и выдаёт фиксированную версию, файлы и разрешение на сеанс. Локальный контроллер проверяет checksum и выполняет воспроизведение.
В MVP допустим веб-проигрыватель с симулятором. Запуск — по действию пользователя, обязательны стерео и локальная остановка. Ограничения при закрытии/приостановке вкладки документировать.
Бинауральное воспроизведение требует наушников либо подтверждённого разделения сигналов между ушами. В web-demo — L/R-тест и подтверждение наушников пользователем; не выдавать это за аппаратное измерение изоляции.
Не сводить сигнал в моно, не переставлять каналы и не включать crossfeed. Каналы используют согласованный тактовый источник. Виброакустический выход — отдельный аппаратный контракт.
Состояния:
`created → precheck → ready → running ↔ paused → completed`
Конечные альтернативы: `cancelled`, `failed`.
Анкеты имеют отдельные `pending / completed / skipped`.
Команды содержат `command_id`, `session_id`, ожидаемую версию состояния. Повтор возвращает прежний результат. Одно устройство выполняет максимум один сеанс.
События имеют ID, последовательность, время возникновения и получения. Контроллер сообщает фактическое состояние. После восстановления связи не выполнять старые команды заново.
Уже загруженный активный сеанс в открытом клиенте должен завершаться и останавливаться при краткой потере интернета. События сохраняются локально и отправляются без дублей. Запуск новых платных сеансов офлайн не обязателен.
## 15. Оценка состояния
Реализовать необязательные одинаковые анкеты до/после, например расслабление, напряжение и бодрость по шкале 0–10.
Показывать ответы и разницу без вымышленных медицинских индексов.
Предусмотреть измерения с типом, значением, единицей, временем, источником, качеством и версией расчёта.
Самооценка, пульс, HRV и ЭЭГ — разные данные. При отсутствии датчика данные отсутствуют. Искусственные значения допустимы только с явной маркировкой и отдельно от реальных отчётов.
HRV и пульс не отображать как измеренную альфа-активность мозга. ЭЭГ-интеграция и её аналитика — отдельный этап с документированным методом и контролем артефактов.
Получать согласие на сохранение измерений, позволять пропустить анкету и управлять удалением. Срок хранения настраиваемый. Разработчику выдавать только агрегаты, защищённые от раскрытия отдельных людей через малые группы.
## 16. API, SDK и данные
API версионирован, например `/api/v1`. OpenAPI входит в поставку.
Ошибки содержат стабильный код, локализованный текст и `request_id`. Списки имеют пагинацию и лимиты. Операции с риском дубля поддерживают `Idempotency-Key`.
Группы API:
- auth/profile;
- каталог приложений;
- приложения/версии/модерация;
- assets и загрузки;
- конвертации и QA;
- покупки, подписки, возвраты, entitlement;
- оборудование, совместимость и BOM;
- аппаратные корзины/заказы/остатки;
- shipping/fulfillment;
- устройства и сеансы;
- оценки и измерения;
- аналитика, финансы и выплаты;
- администрирование.
SDK должен действительно работать и включать:
`createApp`, `createVersion`, `uploadAsset`, `createConversion`, `getConversion`, `validateManifest`, `submitVersion`, `listApps`, `getEntitlement`, `createSession`, `sendSessionCommand`, `getDeveloperAnalytics`, `listHardware`, `getCompatibleHardware`.
Серверные developer keys и пользовательские клиентские сессии разделены. Ключи хешируются, имеют scopes и отзыв, не попадают в браузерный bundle.
Пример SDK должен создать черновик и настоящую конвертацию через API.
Сущности данных должны покрывать пользователей/роли, приложения/версии/assets/профили/jobs/QA, продукты/цены/платежи/подписки/права/журнал/выплаты, продавцов/склады/SKU/совместимость/BOM/остатки/резервы, аппаратные заказы/тарифы/посылки/tracking/возвраты, устройства/сеансы/измерения/согласия, переводы, аудит и inbox/outbox.
UUID, внешние ключи, уникальные ограничения, UTC. Важные инварианты обеспечивать транзакциями и БД.
## 17. Безопасность и эксплуатация
Закрытое хранилище. Пути формирует сервер. Загрузка и выдача — после проверки прав, с ограниченными разрешениями и короткими ссылками.
При завершении загрузки проверять размер и checksum. Нельзя перезаписать одобренный объект через старую upload-ссылку.
Исходник доступен автору и уполномоченной модерации; покупателю — разрешённый delivery asset. Public-превью — отдельный явно опубликованный фрагмент, по умолчанию до 30 секунд.
Использовать поддерживаемую аутентификацию, защищённые сессии, ограничения входа, CSRF для cookie-операций, специализированное хеширование паролей.
Не писать в общие логи секреты, подписанные URL, платёжные данные, диагностические ответы, адреса и телефоны.
Документы доставки доступны покупателю и уполномоченному исполнению. Изменения ролей, файлов, профилей, остатков, адресов, поставщиков, финансов и ручных статусов аудируются.
Удаление профиля не должно каскадно разрушать финансовый журнал. Предусмотреть минимизацию/обезличивание и настраиваемые сроки хранения.
Нужны health/readiness, структурированные логи с request/job ID, метрики очереди, длительности, ошибок и необработанных webhooks.
Описать резервное копирование и проверить восстановление БД.
Передать фактический benchmark конвертации: CPU/RAM, длительность входа, время обработки и пиковая память. Производительность не выдумывать.
### Дополнения v1.1 к разделу 17
- **Ограничение частоты запросов.** Общий лимит на пользователя/адрес и отдельные лимиты на ссылки и части загрузки, оформление заказов и тестовые оплаты, вебхуки, отзывы и жалобы, конвертации. Превышение — `429 rate_limited` с локализованным текстом и `Retry-After`; служебные `/health`, `/ready`, `/metrics`, `/version` не ограничиваются. Лимиты настраиваются без изменения кода.
- **Письма.** Каждое уведомление отправляется письмом один раз (ключ уведомления), на языке получателя, текстом и HTML. Транспорт: журнал (демо), файлы `.eml` (тестовый стенд) или SMTP. Сбой — повтор с экспоненциальной паузой (30 с … 1 ч, до 20 попыток), ошибка видна администратору.
- **Бэкап.** Ежедневно: дамп БД, восстановление во временную базу со сверкой строк ключевых таблиц, суммы журнала проводок, версии миграции и триггеров неизменяемости; архив файлового хранилища; срок хранения настраивается; итог — в метриках и в «Эксплуатации». Копии выносятся за пределы сервера.
- **Мониторинг.** Метрики: ошибки 5xx, очередь и сбои конвертаций, необработанные вебхуки, застрявшие исходящие события, недоставленные письма, возраст и результат бэкапа. Правила оповещений и доставка оповещений письмом входят в поставку.
- **CI.** На каждый коммит: тесты сервера с проверкой соответствия миграций моделям, проверки словарей и шаблонов полей, типы и сборка фронтенда, сквозные сценарии RU/EN, сборка и запуск Docker Compose с ручным циклом бэкапа, проверка конфигурации мониторинга. Итоговая проверка обязательна для слияния.
- **Проверка веб-версии.** Автоматический обход всех страниц для всех ролей, RU/EN, 1280 и 390 px: ошибки консоли, ответы 5xx, горизонтальная прокрутка, непереведённые тексты.
## 18. Критерии приёмки
Автоматизировать критические проверки поведения, прав, денег и DSP.
1. Моно/стерео 44,1 и 48 кГц корректно преобразуются; повреждённые и пустые файлы отклоняются.
2. Изолированный demo-слой содержит 250/260 Гц, разницу 10 Гц; частотный допуск ≤0,1 Гц при документированном методе.
3. На техническом слое противоположная несущая подавлена минимум на 60 dB при подходящем окне/длине теста.
4. Поблочный и непрерывный эталон совпадают в пределах float-точности, например ≤1e-6 до квантования; фазовых сбросов нет.
5. Число отсчётов верно, NaN/Infinity/clipping отсутствуют, true peak master ≤−1 dBTP с указанной погрешностью.
6. При отключённом слое исходник сохраняется с учётом ресемплинга, gain и квантования.
7. Отмена, сбой worker и retry не публикуют частичный результат и не создают двойную ревизию.
8. Настоящий файл проходит загрузку, конвертацию, сборку приложения, модерацию и публикацию.
9. Покупка открывает библиотеку и сеанс; неоплативший пользователь не получает полный файл.
10. Дубли, конкуренция и иной порядок webhooks не дублируют деньги/права; неверная подпись отклоняется.
11. Распределение 10 000 и возврата 4 000 даёт точные 3 000/7 000 и 1 800/4 200; малые возвраты не накапливают ошибку.
12. Продление, отмена, отказ и возврат периода корректно меняют оплаченные интервалы.
13. Пользователи и разработчики не читают чужие материалы, финансы и измерения.
14. Подмена файла/manifest/профиля не обходит модерацию; сеанс закреплён за версией.
15. Браузер не может подменить цену, роль и entitlement; истёкшая ссылка требует нового разрешения.
16. Несовместимая capability блокирует запуск с причиной.
17. Повторы команд не дублируют действия; второй одновременный сеанс устройства отклоняется.
18. L/R сохраняется; пользовательский тест не выдаётся за аппаратное подтверждение изоляции.
19. Загруженный сеанс и остановка работают при потере интернета в открытом клиенте; события синхронизируются один раз.
20. Прерванный сеанс не получает вымышленных измерений; пропуск анкеты работает; HRV не обозначается ЭЭГ.
21. Чистый запуск поднимает сервисы, миграции и demo без внешних секретов.
22. SDK-пример работает через API, ключ отсутствует в браузере.
23. Платёжный адаптер имеет контрактные тесты; live sandbox выполняется при ключах и отражается отдельно.
24. Перезапуск сохраняет данные; восстановление БД проверено.
25. Подбор оборудования показывает полный BOM, имеющиеся и недостающие компоненты и статус совместимости.
26. Аппаратный checkout проходит адрес, доставку, оплату и передачу назначенному поставщику; чужой продавец заказ не видит.
27. Последняя единица не продаётся дважды; резервы/allocated и поздняя оплата корректны; многопродавцовые заказы явно независимы.
28. Нет фиктивной бесплатной доставки при ошибке; адрес/состав пересчитывают тариф; индивидуальное предложение проходит до оплаты.
29. Несколько посылок имеют правильный состав; этикетка не означает delivered; общий статус учитывает все позиции.
30. Timeout не создаёт повторную этикетку; tracking-дубли не искажают историю; источник статуса виден.
31. Возвраты ограничены оплатой, склад пополняется после приёмки, цифровые права отдельно.
32. Продажа оборудования не создаёт цифровой комиссии 30/70; сумма и документы соответствуют снимку заказа.
33. Mock и ручная логистика работают без ключей; test-адаптер имеет контрактные проверки; документы закрыты от посторонних.
34. Оба сквозных сценария полностью проходят на RU и EN.
35. Переключение языка сохраняет карточку, сессию и корзины; URL/SSR/lang/hreflang корректны.
36. Отсутствующий перевод помечен, язык аудио независим, поиск и фильтры корректны.
37. Локаль не меняет цену/валюту/остатки; проверены адреса минимум трёх стран с разными требованиями.
38. API-коды стабильны, тексты и уведомления локализованы; отсутствующие обязательные ключи словарей выявляются автоматически.
39. Файл больше 10 МБ (проверено 60 минут) загружается через веб-интерфейс частями; пропущенная часть докачивается по смещению сервера.
40. Первый готовый трек автоматически становится сеансом 1; сеанс без трека не сохраняется и не вызывает 500.
41. Автор до отправки видит, чего не хватает; после каждого действия видит результат и следующий шаг; модератор видит подтверждение решения.
42. Оценка приложения доступна только при доступе к нему (для платного — после завершённого сеанса); оценка товара — только после доставленной посылки с ним.
43. Разработчик/продавец не может оценить своё, изменить, скрыть или удалить чужой отзыв; может публично ответить, автор отзыва получает уведомление.
44. Средняя оценка показывается с 5 оценок; отзывы со ссылками, контактами, запрещёнными словами и ответы с медицинскими обещаниями уходят на модерацию; жалобы попадают в очередь.
45. Превышение лимита запросов возвращает 429 с локализованным текстом и Retry-After; лимит одного пользователя не влияет на другого.
46. Уведомление доставляется письмом один раз; сбой SMTP приводит к повтору с паузой, а не к потере письма.
47. Ежедневный бэкап проверяет восстановление; неудачный или устаревший бэкап виден в метриках и вызывает оповещение.
48. На ширине 390 px шапка — одна строка, меню доступно с клавиатуры, горизонтальной прокрутки страниц нет.
49. Профиль «Гамма (40 Гц)» даёт 200/240 Гц и разницу 40 ± 0,1 Гц, противоположная несущая подавлена ≥ 60 dB.
50. Шаблоны полей формы компилируются с флагом `v`; ошибки проверки называют поле.
51. Задание конвертации при недоступном брокере не теряется и выполняется после восстановления.
52. CI выполняет все проверки на каждый коммит; слияние при красном CI невозможно.
В отчёте разделять `passed`, `failed`, `not run`. Симулятор не подтверждает реальное кресло, выплату, доставку или изменение мозговой активности.
## 19. Demo, этапы и результат поставки
Создать demo-пользователя, двух разработчиков, модератора, продавца оператора и второго продавца для проверки изоляции.
Добавить приложения разных категорий и статусов, оборудование, компонентный комплект, последний экземпляр, товар под заказ, крупногабаритное кресло с индивидуальной доставкой и заказ с несколькими посылками. Demo-карточки — RU/EN.
Использовать собственные/синтезированные или разрешённые аудиоматериалы. Demo-цены, совместимость, тарифы и измерения явно тестовые.
Этапы:
1. Архитектура, окружение, миграции, роли, хранилище, RU/EN и каталоги.
2. Реальный DSP и бесплатный сквозной сценарий до воспроизведения.
3. Цифровые покупки, подписки, 30/70, возвраты и журнал.
4. Оборудование, BOM, склад, аппаратные заказы, поставщик, доставка и возвраты.
5. SDK, тестовые внешние адаптеры, сеансы и анкеты.
6. Проверки, сбои/восстановление, оба языка и документация.
Передать:
- исходный код, миграции и lock-файлы;
- Docker Compose и `.env.example`;
- README с запуском и demo-сценариями;
- архитектуру и принятые решения;
- документацию DSP, биллинга, аппаратной торговли, склада, доставки и DeviceAdapter;
- OpenAPI, JSON Schema, SDK и рабочий пример;
- словари/шаблоны RU/EN и краткие инструкции на двух языках;
- fixtures, QA-отчёты, benchmark;
- отчёт по всем критериям приёмки;
- список production-зависимостей с точным статусом.
Для реального запуска отдельно потребуются протокол/модель кресла, пределы команд и калибровка, подтверждённый аудиотракт, датчики, утверждённые DSP-профили, платёжные аккаунты, поставщики/SKU/BOM, реальные остатки и условия аппаратных расчётов, склады, упаковка, маршруты/тарифы, данные перевозчика и документов, домен и инфраструктура. Отсутствие этих данных не отменяет работающий core и симуляторы.
За пределами MVP: смешанный checkout цифровых/физических товаров или разных продавцов, общая подписка на каталог, семейный доступ, купоны, ML-рекомендации, нативные мобильные приложения, сторонний исполняемый код, закрытые технологии Монро/Томпсона и собственная клиническая/ЭЭГ-аналитика.
**Определение готового результата:** автор загружает настоящий файл, получает проверенный бинауральный стереотрек и публикует приложение; покупатель приобретает доступ и проходит сеанс; цифровой доход корректно распределяется 30/70. Тот же покупатель подбирает оборудование, оформляет его покупку с международной доставкой, а поставщик получает заказ, комплектует и регистрирует отправку с отслеживанием. Всё работает на русском и английском. Внешние зависимости имеют реальные контракты и честно обозначенный режим подключения.
## 20. Оценки и отзывы (новое в v1.1)
**Объекты:** приложения и товары магазина оборудования (одна модель отзывов).
**Кто оценивает.** Приложение — пользователь с доступом к нему; для платного — после хотя бы одного завершённого сеанса. Товар — покупатель, у которого посылка с этим товаром доставлена (метка «Покупка подтверждена», купленный вариант); для комплекта из компонентов — по заказу, собранному из этого комплекта. Разработчик и продавец (и сотрудники продавца) не оценивают своё. Один пользователь — одна оценка на объект; её можно изменить или удалить.
**Содержание.** 1–5 звёзд; заголовок до 100 символов и текст до 4 000 (заголовок без текста недопустим). К отзыву привязываются версия приложения или вариант товара и язык.
**Показ.** Средняя оценка — с 5 оценок (до этого «Мало оценок»), число оценок, распределение по звёздам, для приложений — средняя по текущей версии; формат чисел по локали. Сортировка: полезные, новые, высокие, низкие; фильтры по версии/варианту и языку; «Полезно» (не для своего отзыва). Рейтинг на карточках каталога, фильтр «4 и выше», сортировка по оценке.
**Ответы.** Один публичный ответ разработчика (приложение) или продавца (товар) на отзыв, редактируемый; автор отзыва получает уведомление. Изменить, скрыть, удалить или обнулить оценки пользователей разработчик/продавец не может; обнуление оценок при новой версии (как в App Store) предусмотрено выключенной настройкой платформы.
**Модерация.** Автопроверка до публикации: ссылки, e-mail и телефоны, запрещённые слова, в ответах — медицинские обещания; такие тексты ждут модератора. Жалобы (спам, оскорбления, персональные данные, реклама, медицинские обещания, другое) ставят отзыв или ответ в общую очередь «Отзывы и жалобы»; модератор публикует или скрывает с примечанием, действия аудируются. Лимиты: не больше N новых/изменённых отзывов в сутки и общий лимит запросов.
## 21. Кандидаты в ТЗ 2.0 (не входят в v1.1)
Решения приняты заказчиком, но меняют области или денежную модель — оформляются отдельной major-версией ТЗ (или отдельным ТЗ блока) после юридической оценки, где она нужна:
| Тема | Задача | Статус решения |
|---|---|---|
| Режимы конвертера 2.0 (сдвиг всего трека, разные несущие L/R) и 5.1 (бинауральные ритмы только во фронтальных L/R, C — голос, Ls/Rs/LFE — загружаются или генерируются; FLAC; вывод HDMI/Type-C/оптика; рекомендации браузеров и звуковых карт) | NAP-063 | вопросы закрыты 31.10.2026; открыто: 5.1 по оптике, судьба текущего режима |
| Кошелёк, модели оплаты (бесплатно, пробный период, тарифы, оплата за использование), автопродление | NAP-064 | требует юридической оценки кошелька |
| Мобильные приложения iOS/Android (только потребление, покупки на сайте) | NAP-066 | в последнюю очередь, после веб-версии 1.0.0 |
| Токен NAP: NAP Credits (закрытые внутренние единицы, $1), инвестиционный токен (доля выручки, RBF), Сербия, ЕС через ECSP | NAP-070 — NAP-078 | требует заключения юриста; отдельное ТЗ блока |
К странице «О версии»