01. StudyFetch: исследование и выводы для LCTRM

Дата проверки: 15 октября 2026 года. Источники — преимущественно собственный сайт и документация StudyFetch. Выводы для LCTRM являются нашими проектными решениями.

1. Что проверено

Просмотрены публичная главная в браузере, форма регистрации, опубликованный снимок Study Plan, документация основных сценариев, каталог инструментов и методов, продуктовые анонсы и политика данных. Публичные внутренние экраны изучены по официальным инструкциям и изображениям, а не через личный аккаунт.

Уровни доказательств: наблюдение — увидено в публичном интерфейсе; документация — описано в руководстве; заявление компании — маркетинг или анонс; не проверено — нужен аккаунт, платёж либо эксперимент.

2. Главный продуктовый вывод

Сила StudyFetch — повторное использование одних источников во множестве учебных действий и сохранение контекста между ними. Study Set связывает материалы, план, помощника и практику. Это подтверждается руководствами по созданию пространства и загрузке материалов.

Для LCTRM стоит взять эту модель связности и дополнить её явным разделением «предмет» и «цель». Студент может хранить материалы по экономике весь год, но отдельно готовиться к коллоквиуму в ноябре и к экзамену в январе.

3. Карта возможностей

Наличие функции и широта настроек подтверждаются публичными материалами. Скорость, корректность ответов и доступность в конкретном тарифе требуют практического тестирования.

4. Изменения, которых недостаточно в исходных материалах

Июньский блог использует название Comprehension, актуальное руководство — Comprehensive. Это пример различий между анонсами и живой документацией. В LCTRM использовать единые русские названия: «Быстро повторить», «Обычный темп», «Разобраться глубже».

5. Восстановленные пользовательские пути

Материалы → обучение. My Sets → создать набор → добавить программу курса или пропустить → загрузить материалы → дождаться обработки → открыть Study Plan → диагностика/тема → практика → результаты. Точка улучшения для LCTRM: создавать предмет автоматически из первой загрузки и показывать полезный результат до большого числа настроек. Основание: импорт.

Тема → сопровождаемое занятие. Включить Guided → выбрать предложенную тему или свою цель → принять/изменить план → пройти активности → вернуться к помощнику → продолжить. Для LCTRM этот путь стоит сделать доступным прямо с главной. Основание: Guided Chat.

Самостоятельный инструмент. Выбрать тест/карточки → источник → материалы → количество/типы → настройки → генерация. Сильная сторона — последовательный мастер; нагрузка — много выбора. В LCTRM первый тест создаётся с разумными настройками, расширенные параметры раскрываются дополнительно. Основание: QuizFetch.

Ошибки → разбор. После теста можно просмотреть ответы и открыть обсуждение конкретного вопроса. В LCTRM добавляется явная связь «ошибка → навык → назначенное повторение» с причиной изменения. Основание: разбор проверки.

6. Наблюдения по дизайну

В публичной главной увидены тёплый почти белый фон, крупный заголовок с засечками, чёрные округлые CTA, спокойная навигация и небольшие фирменные иллюстрации. Официальный снимок Study Plan показывает тёмный левый сайдбар, светлую рабочую область, вертикальный маршрут и вспомогательную правую колонку. Главная, снимок Study Plan.

Для LCTRM переносим иерархию и спокойствие, разрабатываем самостоятельную типографику, палитру, знак и композиции. Большое число разделов в рабочем сайдбаре — проектный риск перегрузки, а не установленная проблема пользователей StudyFetch. Его проверяем на пяти задачах в собственном прототипе.

Форма регистрации в проверенном публичном состоянии предлагает Google либо email. Никакие данные в неё не отправлялись. Для LCTRM основной email-вход должен работать самостоятельно; локальные OAuth-провайдеры добавляются по спросу. Форма.

7. Тарифы и доверие

В американском App Store на дату проверки перечислены Premium Monthly $19.99, Quarterly $29, Yearly $96; голосовые пакеты 1 час $7.49 и 5 часов $25; отдельные покупки Explainer. Это цены конкретного магазина, они не подтверждают веб-тарифы или доступность в РФ. Бесплатные лимиты и состав платных веб-пакетов не установлены. App Store.

Документация описывает отмену через Settings → Billing Portal. Для LCTRM отмена продления и дата завершения доступа должны быть видны в своём кабинете. Инструкция StudyFetch.

Политика StudyFetch допускает использование некоторых загружаемых и создаваемых данных для улучшения собственных моделей, с особыми исключениями для данных Google API. Это не утверждение, что любой внешний провайдер обучается на каждом файле. Для LCTRM предлагаем отдельное понятное правило: материалы приватны по умолчанию, вторичное использование не включено в оказание основной услуги. Политика StudyFetch.

Публичные 92% улучшения оценок на главной — заявление компании о результатах опроса. Оно не является нашей проверкой эффективности и не переносится в маркетинг LCTRM. Главная и контекст исследования.

8. Привлечение: три слоя поискового намерения

У StudyFetch есть каталоги по инструментам, методам и предметам. Каталоги tools и study-methods прочитаны; ссылка на how-to-study присутствует в навигации, но содержание этой страницы в текущем исследовании получить не удалось.

Для LCTRM это даёт три самостоятельных входа: «сделать тест из PDF», «повторять с интервалами», «подготовиться к сессии по экономике». Это гипотеза канала привлечения: публичная структура сайта не раскрывает объём трафика, конверсию и стоимость привлечения StudyFetch.

9. Что брать, изменять и отложить

Взять: связность источников, предметные пространства, контекст преподавателя, разделение тренировок и проверок, источник рядом с объяснением, общий повтор, один следующий шаг.

Изменить: два входа в обучение; русские термины; минимальная первичная настройка; маршруты к разным экзаменам внутри предмета; объяснимая оценка освоения; приоритет локальных учебных материалов и рублёвой оплаты.

Отложить: маркетплейсы плагинов, генерация видео, голос в реальном времени, игры, нативные приложения, институтские продажи. Они становятся отдельными инвестиционными решениями после проверки повторного использования ядра.

10. Практический разбор перед финальным PRD

На этапе 0 провести отдельный тест в разрешённом аккаунте: цифровой PDF на русском, плохой скан, презентация с формулами, противоречивые источники и цель без файлов. На одном наборе сравнить конспект, 20 вопросов, цитаты, возобновление занятия, адаптацию после ошибок и отмену продления. Зафиксировать тариф, дату, устройство, длительность, точность ссылок и проверку ответов предметным экспертом.

Это оставшийся исследовательский пункт перед реализацией; текущий пакет достаточно подробен для обсуждения архитектуры и прототипирования. Отсутствие этого теста не скрывается за словом «досконально».

11. Как объединены два исходных материала

Ключевые требования обоих текстов сохранены: настоящие данные и AI-вызовы, источники, активное участие учащегося, история результатов и работающая адаптация. Подготовленная визуальная концепция отдельно обозначена макетом и не выдаётся за реализованное ядро.

Дополнение v3: инструментальные посадочные

Повторно проверены каталог и специализированные страницы PDF, видео, лекций, заметок, планирования и практики. Новые наблюдения и первичные источники; матрица адаптации под LCTRM.

02. Продукт, сценарии и правила обучения

Статус: проект решений для обсуждения. Числовые пороги ниже — проверяемые продуктовые гипотезы.

1. Обещание продукта

LCTRM помогает превратить учебные материалы или интерес к теме в понятный план занятий и проверить, что действительно усвоено.

Основная формулировка для первого запуска: «Учись тому, что важно тебе». Подзаголовок: «Выбери тему или добавь материалы. LCTRM составит план, поможет разобраться и проверит знания». Обещание бренда: «От учебной цели — к знаниям, которые можешь применить».

Ежедневная ценность: пользователю понятно, что делать сейчас, почему именно это, сколько потребуется времени и как будет проверен результат. Срок необязателен; обещать гарантированное освоение любой дисциплины нельзя.

2. Универсальное самообучение и страницы решений

Универсальная аудитория зафиксирована владельцем. Для проверки нужны 12 интервью из трёх групп: 4 самостоятельных учащихся вне школы/вуза, 4 студента и 4 участника школьного сценария с корректным участием родителей при необходимости. В beta анализировать группы раздельно. Пилотные дисциплины ограничивают корпус проверки качества, а не позиционирование и доступность произвольной цели.

Архитектура допускает любую тему. Гарантируемый в пилоте уровень качества ограничивается проверенными предметными областями. Для практических навыков нужны внешние результаты: выполненная работа, код или демонстрация; текстовый тест не подтверждает полноценное владение навыком.

3. Продуктовые сущности

Один источник может использоваться в нескольких маршрутах того же владельца. Подтверждение навыков между маршрутами переносится только при известном совпадении навыка и уровня, а не по сходству названий.

4. Два входа и первое полезное действие

Вход А: свои материалы

Посадочная нужного инструмента → регистрация с сохранением выбора → загрузить PDF или вставить текст → назвать цель либо выбрать «Разобраться в материале» → увидеть извлечённые темы → получить краткий конспект со ссылкой на источник → начать занятие. Дедлайн и расписание можно уточнить после первого результата.

Вход Б: тема с нуля

Главная → «Начать бесплатно» → регистрация → описать цель → уточнить недостающее → увидеть результаты обучения и программу → пройти/пропустить диагностику → начать первое занятие. Без файлов система использует отдельно обозначенный общий режим; вымышленные источники и цитаты запрещены.

Правила onboarding

• Не спрашивать повторно то, что уже извлечено из запроса. В карточке подтверждения показать предмет, цель, срок и доступное время.
• Не более двух коротких экранов настройки до предварительного плана. Диагностика — отдельное необязательное действие на 3–5 минут.
• Цель без срока допустима. При неизвестном времени предложить 20 минут 4 раза в неделю с возможностью изменить.
• Цель «выучить английский» уточнить через наблюдаемую задачу: «понимать короткие тексты уровня…»; не создавать фиктивно точный срок.
• На главной нет обязательного ввода. Выбранный инструмент и безопасные настройки сохраняются как намерение и восстанавливаются после регистрации. Цель и личные файлы добавляются внутри авторизованного сценария.
• До авторизации доступен демонстрационный материал без загрузки личных документов. Подписка предлагается после первого завершённого цикла либо при достижении видимого лимита.

5. Основные сценарии

UC-00. Личный интерес без экзамена и дедлайна

Ввод: «Хочу разобраться в астрономии, начинаю с нуля, могу заниматься пару вечеров в неделю». Система уточняет интерес и желаемый результат, предлагает короткий редактируемый маршрут, не требует файл или дату экзамена. После первого занятия пользователь объясняет явление своими словами и решает новое задание; следующая встреча учитывает результат.

Успех: произвольная тема проходит тот же настоящий цикл, что академическая; интерфейс говорит о личной цели, а не навязывает «подготовку к экзамену». Для фотографии, музыки и других практических целей маршрут включает практическую работу и критерии самопроверки; выполненный тест не объявляется доказательством всего навыка.

UC-01. Сессия через две недели

Ввод: «Экзамен по микроэкономике через 14 дней, могу 40 минут в день» + 6 лекций PDF + перечень билетов.

1. Система извлекает и показывает дату, режим «по моим материалам», доступные дни.
2. Отмечает читаемые файлы и проблемные страницы; позволяет начать по обработанным.
3. Выделяет темы, сопоставляет билеты с лекциями, показывает непокрытые вопросы.
4. Предлагает диагностику на базовые зависимости и примерное распределение нагрузки.
5. Создаёт маршрут, начиная с приоритетных пробелов.
6. После занятия показывает результат и следующий шаг с причиной.

Успех: пройдена реальная проверка; ошибка в эластичности назначила дополнительную практику, а не только изменила число на dashboard. Отклонение: на все билеты времени не хватает — предложить больше времени, новый срок либо ограниченный приоритетный охват. Объём не сокращается молча.

UC-02. Изучить макроэкономику с нуля

Ввод: «Хочу за шесть недель понимать инфляцию, ВВП и решения ЦБ». Система уточняет исходный уровень и практический результат, строит программу и готовит уроки постепенно. Формулы, понятия и примеры маркируются как общий учебный материал; актуальные ставки и статистика требуют проверенного датированного источника.

Успех: пользователь объясняет причинную связь и решает новую задачу, состояние сохраняется. Отклонение: запрос выходит за текстовую проверку — описать дополнительную практику, не показывать «навык освоен» по прочитанному тексту.

UC-03. Быстро сделать тест из конспекта

Вход с /tools/text-to-quiz → вставить текст → выбрать 10 вопросов → получить предварительное покрытие тем → пройти → посмотреть ошибки. Предмет и временный маршрут создаются автоматически; пользователь может переименовать их. Важен самостоятельный инструмент без обязательной длинной настройки цели.

Успех: тест связан с источником, результаты используются в следующих занятиях. Отклонение: текст слишком короткий — указать недостающий объём/темы и предложить добавить источник; не дополнять его незаметно общими знаниями.

UC-04. Непонятный фрагмент и преподаватель

В занятии выделить абзац → «Объясни проще» → короткая аналогия → наводящий вопрос → самостоятельный ответ. Преподаватель получает контекст текущей темы, источники и последние ошибки. Он предлагает лестницу помощи: вопрос → подсказка → частичный разбор → решение по явному запросу в тренировке.

Успех: помощь не теряет контекст; попытка с подсказкой помечена. Во время итоговой проверки выдача содержательных подсказок отключена на сервере, даже если клиент вручную вызовет tutor API.

UC-05. Вернуться после трёх пропусков

Открыть «Сегодня» → увидеть сообщение «Подстроим план под оставшееся время» → сравнить старую и новую нагрузку → принять изменение. Лёгкая перестановка внутри утверждённых лимитов может происходить автоматически; изменение объёма, срока и ежедневного бюджета требует выбора пользователя.

Успех: завершённые активности не дублируются; просроченные повторения помещаются в ограниченную очередь, а не в один бесконечный день.

UC-06. Два экзамена и 60 минут в день

В одном аккаунте экономика и история, разные даты. Общий scheduler распределяет единый бюджет времени, показывает приоритеты и конфликт. Закреплённое пользователем занятие сохраняется. Успех: сумма назначенного времени по всем маршрутам не превышает доступное; при перегрузке есть объяснение и выбор.

UC-07. Короткое повторение с телефона

«Повторить 8 карточек · 6 минут» → карточка → собственный ответ → раскрытие → самооценка → итог. Следующий интервал рассчитывается повторением; самооценка не становится единственным подтверждением знания. Сессия восстанавливается после звонка или закрытия вкладки.

UC-08. Пробная проверка

Выбрать темы и длительность → увидеть правила → начать → отвечать с автосохранением → отправить либо закончить по таймеру → получить результат → разобрать ошибки → обновить маршрут. Время отсчитывается по серверному дедлайну. В реальном экзамене LCTRM не участвует и не выставляет официальные оценки.

Успех: ключи не раскрыты заранее; один и тот же submit не создаёт две оценки. Незавершённый ответ после истечения времени учитывается согласно опубликованным правилам.

UC-09. ЕГЭ/ОГЭ по выбранному предмету

Выбрать экзамен, предмет, год и уровень → увидеть статус версии программы → пройти диагностику по проверяемым элементам → тренироваться → пройти пробник с критериями → разобрать ошибки. Для российского релиза заменить SAT-пример исходного brief на реальный выбранный предметный пакет.

Успех: задания соответствуют проверенному пакету, экспертные критерии версионированы. До редакционной готовности кнопка не обещает «полный ЕГЭ-тренажёр». Генерация похожего задания не равнозначна официальному экзаменационному варианту. Основание для структуры пакетов — ФИПИ: ЕГЭ, ОГЭ.

UC-10. Плохой скан и противоречащие источники

Скан загружен → статус «Нужна проверка распознавания» → выделены сомнительные страницы → можно исправить текст или заменить файл. Если лекции противоречат друг другу, показать оба фрагмента и даты; пользователь выбирает основной источник. Задания из непроверенного распознавания не входят в подтверждающую проверку.

UC-11. Спорная AI-оценка

Ученик открывает критерии → видит оценённые пункты и аргумент → «Оспорить» → ответ помечается pending_review → пересчёт по исправленному эталону/экспертная очередь. Пока ответ спорный, он не ухудшает подтверждённое освоение. Исправление задания пересчитывает затронутые результаты с сохранением истории.

UC-12. Подписка и данные

Лимит достигнут → видны остаток, цена, период и дата следующего платежа → оплата → доступ после подтверждённого сервером события. Затем пользователь может отменить продление, экспортировать конспект и запросить удаление аккаунта. После окончания подписки чтение своих материалов и результатов сохраняется согласно опубликованной политике; новые генерации ограничены.

6. Состав MVP и следующие релизы

Полноценный календарь-сетка не нужен для первой сессии. Планировщик с ограничением времени нужен с начала архитектуры. Платежи добавляются до платного запуска; экономику генераций измеряем с альфы.

7. Как считать освоение

Пользовательские статусы: «Ещё не начинал», «Разбираюсь», «Тренируюсь», «Пора повторить», «Подтверждено проверкой». Это состояния доказательств, а не психологический диагноз или научно измеренная вероятность знания.

Начальное правило для пилота: навык получает «подтверждено», если есть минимум 3 независимых задания нужного уровня, результат не ниже 80% по сумме баллов и успешная отложенная проверка не ранее чем через 24 часа. На маленькой выборке показывать «данных пока мало». Для сложных навыков методист задаёт дополнительные условия. Порог проверяется экспериментом и не выдаётся за научную константу.

Доказательства хранят task_version, skill_id, уровень, баллы, тип проверки, подсказки, время, тип проверяющего, рубрику и статус доверия. Задания из тренировочного семейства и из контрольного семейства должны различаться содержательно; перестановка вариантов не делает задание новым.

Открытый ответ оценивается по видимым критериям и отмечается «предварительная AI-оценка». Высокая самооценка уверенности модели не превращает её вывод в объективный факт. Ошибки ученика различать по возможности: незнание понятия, неверный метод, вычислительная ошибка, непонимание формулировки.

На dashboard отдельно показывать: пройденные темы; подтверждённые навыки; результат последних проверок; навыки к повторению. «Готовность 70%» допустима только как «подтверждены 14 из 20 навыков этого маршрута», с указанием покрытия и даты. Прогноз балла экзамена до калибровки на реальных результатах не показывать.

8. Адаптация маршрута

1. Проверяющий фиксирует результат и доказательства в транзакции.
2. Learner Model обновляет затронутые навыки по версионированным правилам.
3. Ошибки по предпосылкам получают приоритет перед новым сложным материалом.
4. Scheduler выбирает из доступных действий: короткое объяснение, новый пример, независимая задача, повторение, новая тема.
5. Сначала применяются ограничения: доступное время, зависимости тем, закрепления, блокировки и дедлайн.
6. Внутри допустимого множества учитываются срочность, пробелы и очередь повторений. Весам присваивается версия, они настраиваются по пилоту.
7. Пользователь видит причину: «Добавили задачи на проценты: в проверке ошиблись в 2 из 3 вопросов».
8. Содержательные изменения цели и нагрузки показываются как предложение. Предыдущая версия доступна в истории.

Пример: после занятия №3 у ученика 4/5 по определениям, но 1/3 по применению. Следующая сессия содержит новый прикладной пример и 3 задачи вместо запланированного перехода к следующей теме. Уже подтверждённые определения повторяются позже, а не исчезают из истории.

9. Контроль границ

Система помогает учиться и корректировать собственные материалы. На старте она не заявляет официальную аттестацию, полное владение произвольным практическим навыком и гарантированный экзаменационный результат. Публичное распространение чужих конспектов по умолчанию выключено. Работы, материалы и история ученика изолированы от других аккаунтов.

10. Проверяемое конкурентное преимущество

Долгосрочная ценность создаётся качеством русскоязычных источников, предметных проверок, понятной обратной связи и накопленной достоверной историей обучения. Локализация и маршрутизация уже доступны как идеи другим игрокам. В начале преимущество нужно доказать сравнением на одной задаче и возвращением пользователей, затем укреплять качественными наборами заданий и доверенными процессами.

Дополнение v3: широта инструментов

Созданы 35 посадочных сценариев и единый реестр. Внедрение идёт по P0/P1/P2, с обязательной связью страницы и работающей операции. Подробный путь и технический движок. Страницы прототипа не означают, что все форматы уже поддерживаются сервером.

03. Дизайн, информационная архитектура и UX

Цель дизайна: за несколько секунд ответить «что учить сейчас», а во время занятия оставить внимание на материале. Визуальное направление — современная спокойная учебная среда для взрослых и старшеклассников.

1. Арт-дирекшн v3 «Soft Focus»

Кремовая основа, тёмная слива для основного действия и мягкая пастель для категорий: лаванда, жёлтый, персик, мята и голубой. На главной — выразительный serif и небольшая самостоятельная иллюстрация; кабинет компактнее, а занятие преимущественно нейтральное. Милый персонаж появляется точечно и не двигается постоянно. Цвет не заменяет иерархию и подписи. Действующее направление заменяет зелёную v1.

Связанный прототип v3 в design-concept.html показывает длинную главную, регистрацию, цель, инструмент, результат, программу, занятие, итог, повторение и кабинет. Созданы каталог, 35 инструментальных посадочных и три страницы решений. Это демонстрационные данные и локальные взаимодействия; backend и AI не подключены. Полный путь: спецификация v3.

Тон: доброжелательный, точный, без сюсюканья и давления. «Давай разберём ошибку», «До экзамена 12 дней», «В плане осталось 6 тем». Ошибки — источник следующего действия. Серии занятий и статистика не должны занимать место главной цели.

2. Начальные дизайн-токены

Это начальные значения, перед выпуском проверить контраст всех пар, реальные размеры шрифтов и длинные русские подписи. Лицензию выбранных шрифтов сохранить; файлы шрифтов размещать локально.

Подробные измерения StudyFetch и UX-источники: исследование цветов. Действующая система: MASTER. Предыдущая версия сохранена в design-concept-v1.html.

3. Карта публичного сайта

Названия URL можно оставить латиницей; весь пользовательский текст — русский. Скрытые или будущие функции не используются как активные обещания в меню.

4. Главная страница: композиция v3

1. Hero: универсальное самообучение, наглядная учебная сцена и «Начать бесплатно» → регистрация. Поля загрузки/чата/цели на главной нет.
2. Опоры подхода и пять самостоятельно выбираемых ситуаций: перегрузка, неопределённость старта, мало времени, забывание, страх ошибки.
3. Четыре шага от регистрации до полезного результата.
4. Показ конспекта по материалу, затем один интерактивный вопрос с разбором.
5. Редактируемая программа и посильный ритм.
6. Три равнозначных сценария: для себя, школы и вуза.
7. Частые инструменты и весь каталог.
8. Происхождение, ограничения AI и различие чтения/освоения.
9. Бесплатный старт, FAQ и заключительный CTA.

Инструментальная посадочная содержит конкретную задачу, пример результата, вход и ограничения; загрузка появляется после регистрации. Сохраняется намерение (tool_id), а не личный файл в публичном URL. Подробные структура и пользовательский путь, карта сайта и 35 инструментов.

5. Навигация приложения

На desktop постоянное левое меню: Сегодня · Моё обучение · Повторение · Материалы. Учебные пространства в интерфейсе можно называть направлениями, чтобы навигация подходила и личным интересам. План недели доступен из «Сегодня». Внизу: настройки, тариф, помощь.

Внутри предмета: Обзор · План · Материалы · Практика · Прогресс. Конспекты находятся в материалах, карточки и тесты — в практике. AI-преподаватель — контекстная панель и отдельная точка входа в предмете. Это уменьшает число одновременно видимых разделов.

На телефоне нижнее меню: Сегодня · Моё обучение · Повторение · Ещё. Материалы и настройки — в «Ещё»; добавление доступно контекстно. Внутри предмета горизонтальная прокручиваемая навигация. Во время занятия навигация свёрнута, выход сохраняет место.

В маршруте видны цель, срок, используемые материалы и переключатель режима источников. При смене предмета помощник явно меняет контекст; контент другого предмета не подмешивается молча.

6. Спецификация ключевых экранов

7. Три главных интерфейса

«Сегодня»

Верхняя зона: короткое приветствие, дата и одна доминирующая карточка «Сегодня: спрос и эластичность · 25 минут». В карточке — 3 шага и причина выбора. Под ней — предметы и задачи на неделю. Справа на широком экране — ближайшие экзамены и повторение; на узком они уходят под основную карточку.

Избегать восьми одинаково ярких карточек генераторов. Глобальный поиск вторичен к продолжению. Прогресс «9 из 14 навыков проверено» понятнее большого абстрактного кольца 64%.

План

Модули в вертикальном списке с раскрытием тем и длительностью; состояние передаётся текстом и значком. Текущая тема заметна. Зависимости доступны в пояснении, полноценный граф не обязателен. На первом экране — следующий шаг, а не вся карта знаний.

Переключение «быстро / обычно / глубже» показывает изменение нагрузки и охвата. Пропуск темы не помечает её освоенной. Кнопка «Почему такой план?» открывает краткое объяснение на основании доступного времени, диагностики и источников.

Занятие

Основной столбец материала 640–760 px. Слева компактный список шагов; справа преподаватель по запросу. На экранах до 1100 px второстепенная колонка убирается; на телефоне преподаватель открывается отдельной панелью с сохранением позиции.

Один активный шаг и одна основная кнопка. Практика содержит собственный ввод ответа до раскрытия. Ошибка показывает: что верно, где ошибка, почему и что попробовать. Доступны «Нужна подсказка» и «Сообщить об ошибке». После занятия — краткий итог и конкретное следующее действие.

8. UX сложных и неуспешных состояний

• Генерация: реальные этапы «читаем → выделяем темы → готовим занятие»; не показывать выдуманный процент. Можно уйти и вернуться.
• Нет источника: «В материалах не нашли ответ». Предложение включить общий режим — отдельный выбор.
• OCR: страница и сомнительный фрагмент видны рядом с оригиналом. Исправление не требует новой загрузки всего файла.
• AI недоступен: сохранить ввод, показать повтор и доступные готовые материалы. Не переключать незаметно на демоданные.
• Ошибка сети: различать «ответ сохранён локально» и «синхронизирован». Пользователь знает, что увидит после возврата.
• Лимит: остаток виден заранее; не закрывать уже открытую проверку платёжным экраном. Использовать резерв бюджета сессии.
• Пустое состояние: один пример и одно действие; никаких декоративных неработающих кнопок.
• Удаление: показать последствия для материалов, созданных упражнений и истории. Действие не маскируется под архив.

9. Компоненты дизайн-системы

App shell; sidebar и mobile navigation; breadcrumb; button/input/select; goal composer; upload zone; source row; processing status; source citation; topic/module row; session stepper; question renderer; answer feedback; hint ladder; rubric; card review; schedule item; progress evidence; quota indicator; paywall; dialog/drawer; toast; empty/error/skeleton state.

Для каждого компонента: размеры, светлая/тёмная темы, hover/focus/disabled/loading/error, keyboard, мобильный вариант и длинный русский текст. Сначала настроить токены, затем собирать экраны; не стилизовать одинаковый компонент заново на каждой странице.

10. Доступность и адаптивность

Контрольные ширины: 360, 390, 768, 1024, 1440 px. Без горизонтального скролла страницы; длинная формула или таблица прокручивается внутри своего блока. Интерактивные зоны ориентировать на 44×44 px, видимый focus, логичный порядок Tab, подписи полей, озвучиваемые статусы и ошибки.

Счётчики и графики имеют текстовый эквивалент. Цвет не является единственным признаком результата. Шрифт масштабируется до 200%; после открытия диалога фокус управляется и возвращается. Аудио сопровождается текстом. Таймер и допустимые адаптации проверок обсуждаются отдельно для учебного, а не официального экзаменационного режима.

11. Процесс дизайна и критерии готовности

1. Карта сценариев и черновые экраны двух входов.
2. Два небольших арт-направления; выбрать одно по читаемости и доверию на реальной задаче.
3. Детальные макеты главной, onboarding, «Сегодня», плана, занятия и результата.
4. 5–7 пользователей решают пять задач: создать цель; загрузить файл; продолжить; найти причину оценки; перенести занятие.
5. Исправить повторяющиеся затруднения; затем оформить библиотеку компонентов и остальные состояния.
6. Передавать в разработку состояния, тексты, правила адаптивности и поведение, а не только красивые кадры.

Готовность: минимум 4 из 5 участников без помощи находят продолжение обучения и источник объяснения; все критические ошибки понятны; основные сценарии проходят на телефоне. Это пороги решения для небольшого качественного теста, а не статистическая оценка рынка.

04. Архитектура и инженерные требования

При первоначальной подготовке плана рабочая директория была пуста. Сейчас есть статический прототип, генератор страниц и реестры; серверного приложения и миграций ещё нет. Ни приложение, ни инфраструктура этим документом не развёрнуты. Решения ниже — рекомендуемая архитектура для этапа проектирования.

1. Стек и границы

Начать с модульного монолита и отдельного worker-процесса. Не нужны одиннадцать микросервисов или автономных LLM-агентов из названий модулей исходного brief.

Конкретные версии фиксируются в lockfile при начале разработки после проверки поддерживаемости. Выбор библиотеки авторизации и движка очереди оформляется коротким ADR; не оставлять это свободным решением каждого AI-сеанса.

2. Размещение и поток данных

Браузер
   → Web / серверные API в РФ
       → PostgreSQL: аккаунт, маршруты, попытки, расписание
       → Приватное файловое хранилище: оригиналы и производные
       → Очередь → workers: чтение файлов, OCR, генерация
       → AI gateway → допущенный провайдер
       → Платёжный провайдер → подтверждённый webhook
       → Метрики и аудит без содержимого личных файлов

Базовый вариант — российское размещение БД, файлов, авторизации, резервных копий и рабочих процессов. Внешняя обработка AI, embeddings, OCR, аналитики, email и ошибок входит в карту данных. Российский бренд поставщика сам по себе не подтверждает нужный маршрут обработки; проверяются договор, конкретный сервис и настройки.

Обоснование требования локализации и задачи юридической проверки: ст. 18 152-ФЗ. Хранение в РФ не заменяет остальных обязанностей оператора.

3. Доменные модули

4. Модель данных

Все пользовательские записи имеют владельца и временные поля. Ниже логические таблицы; окончательная нормализация — результат ERD на этапе 0.

Связи проверять составными ключами/условиями доступа: journey_id или source_id сами по себе не дают права присоединить чужую запись. Оригинальная попытка содержит снимок версии задания и критериев; исправление контента не уничтожает историю оценивания.

Знания по навыкам сначала изолированы контекстом программы. Межмаршрутный перенос допускается по устойчивому идентификатору и совместимому уровню. Глобальная онтология всех знаний не нужна для MVP.

5. Обработка материалов

1. Сервер создаёт запись загрузки и временный URL, проверяет владельца и лимит.
2. После передачи файла проверяет тип по содержимому, размер, контрольную сумму и безопасность; расширения недостаточно.
3. Parser работает с ограничением CPU/RAM/времени и без свободного выхода в сеть. Архивы, макросы и исполняемый контент не запускаются.
4. Извлекает текст по страницам, заголовки, таблицы и формулы насколько поддерживает выбранный parser.
5. Определяет плохие/пустые страницы. OCR запускается адресно, дорогой путь имеет отдельную квоту.
6. Сохраняет оригинал, версию, страницы и извлечённый текст; сомнительное распознавание помечает.
7. Делит по структуре и размеру, сохраняет точную связь со страницей/диапазоном. Деление не должно разрывать задачу и её условия.
8. Индексирует разрешённый контент; выделяет темы и кандидатов на связь с навыками.
9. Проверяет покрытие цели; показывает пользователю пробелы и предложенные новые темы.
10. Готовит краткий результат и первое занятие. Остальной контент создаётся по потребности.

Статусы: uploaded → checking → extracting → needs_review / indexing → ready / partial / failed. У каждого сбоя есть причина и возможность повторить нужный этап. Пилотный предел — 50 МБ и 200 страниц на PDF; окончательный лимит определяется замерами стоимости и времени.

Повторная загрузка того же файла одним владельцем может переиспользовать извлечение. Межпользовательская дедупликация содержимого выключена на старте. Изменение источника создаёт версию; зависимые конспекты и задания получают отметку устаревания.

При удалении источника прекращается retrieval, удаляются оригинал, текст и embeddings; производные материалы с воспроизведением исходного содержимого также входят в задачу удаления. Минимальная история попыток сохраняется только в допустимом объёме и по утверждённой политике; пользователь видит последствия до удаления.

6. AI и retrieval

Сравнить как минимум два допустимых провайдера на одном русском benchmark. Кандидаты для проверки — Yandex AI Studio и GigaChat API. Выбор не сделан по известности бренда; отдельно проверяются качество, контракт, стоимость, доступность и места обработки.

AI gateway получает тип задачи, разрешённые источники, schema и бюджет. Любой output валидируется по схеме, объёму, допустимым ID и ссылкам. Не более двух ограниченных попыток исправления структуры, затем явная ошибка и сохранение черновика. Самосогласие нескольких генераций не считается доказательством фактической истинности.

Два режима источников

По моим материалам: retrieval только по допущенным источникам предмета/маршрута; ссылки ведут в сохранённые страницы. Если подтверждения нет — об этом сообщается. Общие знания не выдаются за цитату из лекции.

Общее обучение: модель составляет структуру и объяснения с маркировкой происхождения; внешние фактические ссылки берутся только из реально полученных ресурсов. До подключения надёжного web retrieval не генерировать датированные новости, ставки и «проверенные ссылки» по памяти.

Сначала фильтровать доступ на сервере, затем выполнять текстовый/векторный поиск внутри разрешённого множества. Retrieval другого пользователя нельзя «исправить фильтром после генерации». Для цитирования проверять существование источника и смысловую поддержку утверждения на выборке экспертом.

Документы — недоверенные данные: инструкции внутри PDF не меняют системные правила и не дают инструментам разрешения на действия. Разрешённые действия преподавателя типизированы: предложить практику, объяснить фрагмент, открыть шаг. Изменение цели, объёма и подписки не выполняется по тексту модели.

Учитывать независимые настройки хранения провайдера. Например, Yandex отдельно описывает служебные логи, трейсинг, данные API и использование запросов для улучшения; выключение последнего не отключает остальные. Политика хранения. Наше решение: минимизировать передаваемые данные, отключать вторичное использование доступными настройками, отдельно контролировать сохранённые API-объекты и договорные условия.

7. Оценивание

Для каждого типа задания определён модуль evaluate(answer, task_version, policy) → result.

Ключи и решения никогда не отправляются клиенту до разрешённого момента. Итоговая попытка фиксирует режим без помощи. Сеть и повторный submit не должны удваивать доказательства. Спорная оценка обратима, её исправление запускает перерасчёт затронутых состояний и расписания.

8. Транзакция адаптации и расписание

submit → grading_result → skill_evidence → skill_state → outbox_event выполняется атомарно, где результат готов синхронно. Для AI-проверки попытка переходит в pending, а итог применяется отдельной идемпотентной транзакцией.

Событие с уникальным ID запускает пересчёт следующих сессий. Каждое планирование использует версию mastery и доступности; при конфликте обновляется относительно свежих данных. Ограничения имеют приоритет над весами рекомендаций. UTC хранится вместе с часовым поясом аккаунта; отображение и локальные даты вычисляются из него.

Интервалы повторения рассчитываются кодом. Можно начать с простой версионированной схемы и затем сравнить с готовым алгоритмом после проверки лицензии и качества. Отдельно хранить самооценку карточки и независимую проверку.

9. Контракты основных операций

Ошибки имеют код, понятное сообщение, возможность retry и correlation ID. Для длительных операций клиент получает job ID и статус; не держать импорт внутри одной долгой HTTP-функции.

10. Надёжность и стоимость

Jobs имеют уникальный ключ, retry с задержкой, предел попыток, timeout и очередь окончательных ошибок. Повторный запуск после падения не создаёт второй платёж, двойную квоту и одинаковые активности. Резерв AI-бюджета выделяется до операции, фактический расход сверяется после неё, неиспользованный резерв освобождается.

Не генерировать все уроки всей программы сразу. Сохранять готовые версии; кэшировать только в пределах разрешённых данных. Учёт токенов, OCR, хранения и retry ведётся с первой альфы. Provider fallback допускается только среди заранее одобренных маршрутов обработки данных.

Предлагаемые SLO после стабилизации: доступность основных чтений 99,5% в месяц; p95 обычного API до 800 мс при оговорённой нагрузке; первый токен преподавателя до 5 секунд; короткий цифровой PDF до 30 страниц → первые темы до 90 секунд p95 на эталонном стенде. Это цели, подлежащие нагрузочному измерению, а не обещания текущей реализации.

Резервное копирование: целевой RPO ≤1 час и RTO ≤4 часов, если выбранный тариф инфраструктуры это обеспечивает. Проверить восстановление на staging, включая файлы. Удаления из резервных копий выполняются по политике retention с защитой от повторного появления удалённых аккаунтов при restore.

11. Безопасность и доступ

Серверные проверки владения на каждом чтении/изменении; private buckets; короткие подписанные ссылки; HttpOnly/Secure сессии; CSRF и проверка Origin для изменяющих действий; rate limits; минимальные ключи сервисов; отсутствие ключей в браузере.

Администратор видит агрегаты и очередь проблем. Просмотр содержимого по обращению — отдельная роль, основание, ограничение времени и аудит. Тестирование доступа двумя независимыми аккаунтами обязательно. Форматирование AI-текста очищается от активного HTML и небезопасных ссылок.

Логи не содержат полные документы, ответы ученика и секреты по умолчанию. Ошибки, метрики и трассировки проверяются на утечки содержимого. Сырые промпты сохраняются только в специально разрешённом диагностическом режиме с ограниченным сроком.

12. Структура репозитория и проверка

apps/web                 публичный сайт и кабинет
apps/worker              импорт, генерация, перерасчёты
packages/domain          правила оценивания, mastery, scheduler
packages/contracts       схемы API, заданий и AI-ответов
packages/ai              адаптеры и retrieval
packages/ui              общие компоненты и токены
db/migrations            версионированная схема
evals                    обезличенные эталонные наборы
docs/adr                 короткие архитектурные решения

Если команда мала, часть packages можно держать как модули web/worker без отдельной сборки. Проверки: линтер и типы; unit для бизнес-правил; интеграционные тесты БД/доступа/jobs/webhooks; сквозные сценарии; отдельные AI-evals. Демо-режим отделён конфигурацией и заметной маркировкой, в production отсутствует скрытая подстановка заранее заданных AI-результатов.

Дополнение v3: движок инструментов

К архитектуре добавлены контракты инструментов, 35 связей страницы и реализации, адаптеры и операции и схема запроса. Они расширяют модель source/task/artifact, определяют возврат намерения после регистрации, разрешённые сочетания и выпуск каждой функции только с работающим backend.

Реализация локальной альфы · 16 октября 2026

Созданы сервер Fastify/Node ESM, встроенная SQLite с WAL и один worker. OpenAI выбран владельцем как AI-провайдер и интегрирован через официальный SDK. Это отличается от предложенного production-стека; причины, границы и миграционные задачи описаны в RUNNING. API-ключ при разработке не был предоставлен, живые генерации пока не подтверждены.

05. Дорожная карта, задачи, команда и бюджет

Плановый горизонт — 18 недель до ограниченного платного запуска, включая резерв. Это оценка для небольшой опытной команды при доступных поставщиках, материалах и владельце продукта. Отсчёт начинается после фиксации команды; календарная дата запуска пока не назначена.

1. Вехи и критический путь

Исследование и решения → сценарии и дизайн → данные и доступ
    → цель/источник → программа → занятие → оценка
    → доказательства → реальная адаптация → повторное использование
    → защищённые платежи и эксплуатация → ограниченный запуск

Дизайн, предметная проверка и юридическая подготовка идут рядом с разработкой. Они не переносятся в конец. Расширенные медиаформаты и поисковое масштабирование не задерживают основной учебный цикл.

2. План по неделям

К недельной встрече прилагаются работающий сценарий, изменения метрик, расход AI, новые риски и решение на следующую неделю. Проценты «готовности проекта» без демонстрации сценариев не используются.

3. Backlog разработки

Владельцы: Product — владелец/продакт; Design — дизайнер; FE — интерфейс; BE — backend; AI — AI/RAG; Method — методист; QA — проверка; Ops — эксплуатация. Один человек может совмещать роли.

Строки roadmap можно объединять в спринты, но блокирующие зависимости должны сохраняться. Окончательные оценки в днях/points ставятся после ERD, прототипа и технического spike; случайные точные числа по каждой задаче сейчас создадут ложную уверенность.

4. Release gates

G0 — можно начинать реализацию: зафиксированы универсальное позиционирование, три группы сценариев, контур данных, проект дизайна, benchmark и правила приёмки.

G1 — внутренняя альфа: оба входа приводят к реальному занятию; результат сохраняется и меняет следующий шаг. Без этого карточки и маркетинговая главная не означают готовность продукта.

G2 — закрытая beta: права проверены, основной мобильный путь работает, вопросы соответствуют источникам, проблемы имеют видимые статусы, есть поддержка и учёт стоимости.

G3 — платный запуск: качественные и эксплуатационные пороги соблюдены; прошли платежи, возвраты, отмена, согласия, restore и удаление. Retention и экономика не показывают заведомо убыточный сценарий использования.

G4 — масштабирование: качество сохраняется на новых данных; повторное обучение и unit economics измерены на нескольких когортах. До этого рекламный бюджет ограничен экспериментом.

5. Команда и распределение

Два опытных инженера: один ведёт интерфейс и пользовательские пути, второй — данные, jobs, доступ, оценивание и платежи. AI-инженер на 0,5 ставки ведёт ingestion, evals и провайдеров; может совмещаться с backend, если компетенция подтверждена. Дизайнер активно работает первые 6–8 недель, дальше сопровождает. Методист проверяет продуктовую логику и корпус весь цикл. QA подключается сначала к спецификации, затем активнее к beta. Владелец продукта принимает решения и ведёт исследования.

Один разработчик с AI-инструментами может сделать узкую вертикаль быстрее полноценного MVP, но для описанного объёма рабочая гипотеза — 5–8 месяцев и последовательное подключение дизайнера/методиста/QA. Сокращать срок следует сокращением объёма и числа форматов, а не отменой проверки прав и качества заданий.

6. Расчётный бюджет сценария

Следующие ставки — входные допущения финансового планирования, не исследование зарплат и не предложения подрядчиков. 18 недель округлены до 4,2 месяца; необходимо отдельно согласовать договоры и налоговый режим.

Не включены отдельная зарплата владельца продукта, масштабная реклама, большая редакция экзаменационных банков и регулярная эксплуатация после запуска. Если перечисленные договорные ставки не включают какие-либо налоги/накладные расходы, они добавляются к смете. Нельзя обещать этот объём за 4 недели на основании скорости генерации интерфейса.

Бюджет lean-проверки фиксируется отдельно: сначала 2 недели исследований и прототип, затем 4–6 недель узкого работающего цикла. Оплата следующих этапов привязана к вехам, а не к красивому статичному dashboard.

7. Задачи первых десяти рабочих дней

8. Формат задач для AI-разработки

Каждая задача содержит пользовательский результат, разрешённые файлы/модули, контракты, входные данные, состояния ошибок, критерии приёмки и способ демонстрации. Например: «Реализовать objective scoring и однократный submit с интеграционным тестом повторного запроса; показать, что результат обновил навык и назначил следующую практику».

Один большой промпт из исходного материала использовать как vision, не как неделимую инженерную задачу. После каждого блока сохранять миграции, инструкцию запуска, тестовые данные без личной информации и актуальный журнал решений.

Дополнение v3: каталог и связанный прототип

Уже подготовлены длинная главная, связанный демонстрационный путь, 35 посадочных задач и три страницы решений. Следующая разработка — V3-01–V3-12 из технического дополнения. Каталог задаёт полный проектный объём; оценки 18 недель и бюджета относятся к ограниченному первому выпуску, не ко всем 35 возможностям. P1/P2 требуют отдельных spike, оценки и gates.

06. Российский рынок, локализация и экономика

1. Что означает адаптация под РФ

Русский интерфейс — только часть работы. Нужны русскоязычные документы, локальная учебная терминология, оплата, поддержка, договоры, соответствующее размещение данных и качественное оценивание по выбранным программам.

Формы короткого ответа должны учитывать «ё/е» по предметному правилу, десятичную запятую, единицы измерения и русские математические обозначения. Нормализация не должна принимать фактически другой ответ. Формулировки заданий, даты и культурные примеры проверяются носителем языка и методистом.

2. Конкурентное поле и реалистичное позиционирование

Эта таблица описывает альтернативы, а не доказывает отсутствие функций у всех конкурентов. Например, Фоксфорд уже публично предлагает расписание, пробники, анализ слабых тем и ручную проверку письменных заданий. Следовательно, «у нас есть план и адаптация» недостаточно для уникального позиционирования. Фоксфорд: подготовка к ЕГЭ.

Кандидаты на технические интеграции и одновременно часть пользовательских альтернатив: Yandex AI Studio, GigaChat. Детальный обзор всего российского рынка и оценка TAM не проводились; их не заменяют выдуманные рыночные цифры.

3. ЕГЭ и ОГЭ как отдельные продукты качества

На проверенной странице ФИПИ размещены проекты документов ЕГЭ-2027. Для LCTRM хранить год и статус программы, не выдавать проект за утверждённую редакцию. Проверять изменения перед выпуском соответствующего пакета. ФИПИ: ЕГЭ. Для ОГЭ вести отдельные спецификации и критерии. ФИПИ: ОГЭ.

Каждый предметный пакет содержит: перечень проверяемых элементов, типы заданий, уровень, критерии и баллы, зависимости навыков, эталоны, исключения, дату проверки методистом и основание использования материалов. Первичный и тестовый балл разделяются; шкалы разных лет не смешиваются.

Открытость банка не трактуется автоматически как разрешение массового коммерческого копирования. Отдельно проверить права и условия использования; для продукта подготовить собственные экспертно проверенные задания либо лицензировать контент. Ссылки на официальный источник можно показывать без заявления об аффилированности.

Начать с одного предмета и определённого класса задач, выбранных по спросу пилота и доступности методиста. Пакет с развёрнутыми ответами требует системы рубрик и процедуры спора. Запуск сразу всех экзаменов повышает контентный риск и существенно расширяет смету.

4. Персональные данные и договорная подготовка

Проектное решение — базовое размещение пользовательских данных в РФ. Статья 18 152-ФЗ задаёт ограничения на использование зарубежных баз при сборе персональных данных граждан РФ. Это основание для пересмотра иностранного облачного backend из исходного brief, а не заключение о том, что одно место БД решает все вопросы. Текст статьи.

До публичного запуска специалист проверяет применимые основания обработки, уведомления, трансграничные потоки, безопасность и возрастную модель с учётом фактической бизнес-схемы. Ниже рабочие результаты этой задачи, а не готовое юридическое заключение.

Закрытый пилот можно организационно начать с совершеннолетних; это рекомендуемое ограничение пилота, а не отказ от школьной аудитории в продукте. Маркетинговые сообщения и вторичное обучение моделей не объединяются незаметно с согласием на основную услугу.

5. Платежи

Для MVP выбрать одного провайдера. ЮKassa — кандидат: её документация описывает СБП и сохранение способа оплаты, включая ограничения банков для автоплатежей. Доступность конкретного метода подтверждается при подключении магазина. СБП по API, автоплатежи.

Платёжный путь: тариф → точная сумма/период/условия → подтверждение у поставщика → проверенное серверное событие → доступ → чек по применимой схеме → история платежей и отмена. Успешный redirect не включает тариф сам по себе. При сомнительном webhook проверять актуальный статус через серверный API и правила поставщика.

Нужны случаи: дубль и изменение порядка событий, отменённый платёж, сбой фискализации, неуспешное продление, возврат и частичный возврат, смена тарифа, отключение автопродления. Кассовую схему определить с бухгалтером/провайдером; наличие платёжного API не означает автоматическую готовность всех чеков. Решения ЮKassa по чекам.

Годовой тариф имеет смысл после измерения сезонного спроса. Для сессии отдельно протестировать разовый доступ на 30 дней с явно указанным отсутствием автопродления.

6. Тарифные гипотезы

Все суммы и лимиты — предложения для теста. Публичная единица расхода должна быть понятна: обработанная страница, завершённая генерация, учебная сессия. Внутренние токены не нужны пользователю. «40 сессий» требует определения: например до 30 минут активной работы и ограниченного числа AI-объяснений; сложные регенерации и OCR имеют отдельные явно описанные пределы. Пользователь видит остаток до начала.

Не вводить «безлимитный AI». Автосохранение, чтение уже созданного материала и просмотр старого результата не расходуют генерационные квоты. Неуспешная операция не съедает пользовательский лимит; внутренние затраты всё равно учитываются в экономике.

7. Unit economics: расчёт, а не обещание

Вклад на плательщика = полученная выручка − платёжные комиссии − возвраты − AI/OCR − переменные хранение/трафик/поддержка.

Налоги, постоянная команда, юридические расходы и платное привлечение считаются отдельно. Для общей экономики выручка от плательщиков должна также покрывать бесплатное использование; его нельзя терять при расчёте «маржи подписки».

Иллюстрация для тарифа 690 ₽ и 1 000 плательщиков, все затраты условные:

Этот пример не подтверждает тариф поставщика, налоговую нагрузку или прибыльность бизнеса. Если AI/OCR платного пользователя стоит 300 ₽ вместо 120 ₽, последний вклад снижается до 252,05 ₽. При четырёх оплаченных периодах и неизменных допущениях получается 1 728,20 ₽ суммарного вклада на плательщика до CAC и постоянных затрат; это сценарий, не оценённый LTV.

При условном CAC 600 ₽ и вкладе 432,05 ₽ простой срок возврата CAC — около 1,4 оплаченного периода. При фактической жизни пользователя в один сезон это может быть неприемлемо. До масштабирования измерить сезонные когорты, renewal, возвраты и реальные затраты p50/p90, включая долю бесплатных пользователей.

8. Привлечение и удержание

Первые пользователи: добровольные пилоты из сообществ самообразования, студентов и школьных сценариев; знакомые преподаватели как исследовательские партнёры; приглашения через владельца. Когорты охватывают разные цели, а не только сессию. Публикации и сообщения этим документом не отправлялись. Перед рассылкой необходим конкретный согласованный текст и аудитория.

Продуктовый канал — понятная бесплатная задача: PDF → небольшой тест/конспект → занятие → результат → сохранённый маршрут. Точечный контент и объявления проверяют конверсию в завершённый цикл, а не только в регистрацию.

Поиск и контент: в первый публичный выпуск включить /solutions/self-learning, /solutions/school, /solutions/students и 3–5 инструментальных страниц. В примерах обязательно представлены личный интерес, школьные задачи и вузовская подготовка. На каждой странице работающий вход, собственный пример результата, ограничения и переход без потери контекста. Затем методы обучения и предметы. Не производить сотни похожих страниц до проверки полезности и индексации.

Технически подготовить sitemap, canonical, robots/noindex для личного кабинета, серверный HTML публичных страниц, понятные заголовки и измерение пути. Частные материалы не индексируются. Доступ к материалам защищается авторизацией; noindex не является защитой данных.

Удержание: следующий шаг на «Сегодня», умеренная очередь повторений, видимые причины прогресса, мягкое восстановление после пропуска. Уведомления включаются пользователем, учитывают часовой пояс и тихие часы. Рост через шаринг допускается только для разрешённых учебных материалов и отдельно от личной истории ответов.

9. Домен и запуск

Домен считается доступным владельцу. Текущее содержимое не влияет на продуктовый план. Для staging использовать отдельный согласованный адрес; существующий проект остаётся до подготовленного переключения. В плане выпуска: сохранить конфигурацию, подготовить новый сервис и сертификаты, проверить URL/письма/платежи, затем выполнить согласованное переключение и иметь откат.

Не перенаправлять автоматически все старые страницы на новую главную ради формального сохранения трафика. Судьбу старого проекта и релевантные перенаправления определить отдельной задачей при публикации. Никаких DNS-изменений в рамках текущего исследования не выполнено.

07. Проверка качества, метрики и выпуск

Все пороги — начальные критерии принятия решений для пилота. Они не являются индустриальными нормативами и корректируются после первых данных с объяснением причины.

1. Критические гипотезы и эксперименты

2. Продуктовые метрики

North Star: число активных пользователей за неделю, завершивших учебный цикл с независимой проверкой и назначенным следующим действием. Дополнительный качественный сигнал — доля таких пользователей, успешно прошедших отложенную проверку.

OMTM первого квартала: доля активированных пользователей, вернувшихся и завершивших второй цикл в течение 7 дней. Такая цель лучше отражает полезность, чем число созданных конспектов.

Не сравнивать сырые проценты знания между разными предметами и генерациями без сопоставимого покрытия. Подъём балла после показа тех же ответов не доказывает перенос навыка. Большие рекламные заявления требуют заранее заданной методики и достаточной выборки.

3. События аналитики

goal_started, goal_confirmed, source_uploaded, source_ready, source_needs_review, diagnostic_completed/skipped, plan_accepted, session_started/resumed, answer_submitted, hint_used, assessment_graded, mastery_evidence_added, plan_adapted, review_completed, source_citation_opened, content_reported, quota_reached, checkout_started, payment_confirmed, renewal_cancelled.

Общие поля: псевдонимный user ID, cohort, путь входа, subject/category, режим источников, версия правил и контента, время, длительность, статус. В продуктовую аналитику не отправлять сырой текст цели, документов, вопросов и ответов; необходимое содержимое хранится в защищённых доменных данных с контролем доступа.

Путь «генерация успешна» и путь «пользователь завершил обучение» измерять отдельно. Удалённый или отказавшийся пользователь не должен продолжать появляться в идентифицируемых событиях вопреки утверждённой политике.

4. Корпус качества

Начальный benchmark выбора модели — 50 вручную описанных учебных примеров. Перед beta расширить до не менее 200 сгенерированных заданий и 100 проверяемых утверждений с цитатами; использовать разные источники и дисциплины, а не один красивый пример.

Корпус включает цифровой PDF, скан с шумом, две колонки, формулы, таблицы, кириллицу, недостаток материала, противоречия и внедрённую инструкцию «игнорируй правила». Персональных данных реальных учащихся в общем benchmark нет; права на материалы определены.

Предварительные gates: 100% выдаваемых структур проходят схему; не менее 95% заданий в экспертной выборке пригодны без исправлений; не менее 95% проверенных цитат поддерживают утверждение. Критические ошибки — неверный ключ в подтверждающей проверке, утечка чужих материалов и выдача ответов экзамена — исправляются до релиза независимо от среднего процента. Проценты публиковать с размером и составом выборки; отсутствие ошибки в небольшой выборке не доказывает нулевой риск.

Новая версия модели, промпта или parser проходит regression evals перед включением. При ухудшении есть feature flag и возврат предыдущей конфигурации. Экспертный review нужен и при идеально валидном JSON.

5. Матрица инженерных проверок

В accessibility-проверке использовать официальный перечень WCAG 2.2 как основу требований. Выполнение отдельных пунктов не выдавать за полную подтверждённую сертификацию.

6. Чек-лист выпуска

• ☐ Два ключевых сценария реально используют серверные AI-вызовы и сохраняют всё необходимое.
• ☐ Ошибка ученика меняет следующий шаг; просмотр и проверка разделены.
• ☐ Есть работающий путь «не хватает материала» и «неверная оценка».
• ☐ Нет критических дефектов доступа, заданий и платежей; назначены ответственные за оставшиеся.
• ☐ Пользовательские квоты проверены в условиях retry и одновременных запросов.
• ☐ Выполнены проверки мобильного сценария и доступности.
• ☐ Одобрены схема обработки данных, договоры, платежи и контентные права.
• ☐ Настроены поддержка, мониторинг ошибок, jobs, затрат и неуспешных платежей.
• ☐ Восстановление и откат выполнены на staging; есть инструкция и дежурный ответственный.
• ☐ Секреты изолированы, production demo-mode отсутствует, тестовые платежи отделены.
• ☐ Публичные страницы соответствуют работающим функциям; личные страницы закрыты доступом и не индексируются.
• ☐ Подготовлен отдельный согласованный план переключения домена с возвратом к предыдущему сервису.

Выпускать поэтапно: внутренняя команда → 30–50 beta → 100–200 приглашённых → платный ограниченный запуск → расширение. Число приглашённых не означает число активных или завершивших обучение.

7. Реестр рисков

8. Реестр предварительных решений

Неполученный ответ на продуктовый вопрос не превращается в молчаливое согласование. Этот пакет фиксирует предложенный рабочий вариант; реализация, внешняя публикация и переключение домена — следующие отдельные действия.