Теоретическая основа проекта собрана в главном концепте [«учиться-легко.рф — обучение чтению как дешифровке письменного кода»](/concepts/uchitsya-legko-rf-obuchenie-chteniyu-kak-deshifrovke-pismennogo-koda). Он является центральной точкой проекта: описывает общую модель, текущее состояние и связывает частные концепты.

Сейчас проект находится на стадии **Idea**. Сформирована базовая теория чтения как восстановления информации по письменному коду. Зафиксированы информационные сущности, на которых строится обучение: объект и ситуация, понятие, изображение, устное слово, звучание, написанное слово, буквы и более крупные структурные части слова.

Ключевые составляющие теории:

* [Чтение — это распознавание слова и восстановление смысла, а не последовательное озвучивание букв](/concepts/chtenie-eto-raspoznavanie-slova-i-vosstanovlenie-smysla).
* [Письменное слово связывает несколько представлений одного и того же содержания](/concepts/pismennoe-slovo-svyazyvaet-neskolko-predstavleniy).
* [Обучение чтению должно идти от известных опор к неизвестному коду](/concepts/obuchenie-chteniyu-ot-izvestnyh-opor-k-neizvestnomu-kodu).
* [Устный словарь — база распознавания при обучении чтению](/concepts/ustnyy-slovar-baza-raspoznavaniya-pri-obuchenii-chteniyu).
* [Длинное слово должно раскрываться через знакомые структурные части](/concepts/dlinnoe-slovo-cherez-znakomye-strukturnye-chasti).
* [Подсказки должны постепенно исчезать по мере освоения связей](/concepts/podskazki-dolzhny-postepenno-ischezat).

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

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

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

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

учиться-легко.рф

## Задача

Вынести общую логику исполнения `VoiceScenario` в единый runtime-модуль и использовать его одновременно в синтезаторе и визуализаторе.

Сейчас логика `prepareScenario`, `evaluateBezier`, `updateAutomations`, `executeCommand` и вычисление текущего `VoiceControlState` фактически дублируется. Это создаёт риск расхождения: визуализатор может показывать не то состояние, которое реально использует DSP.

## Что нужно сделать

- Создать общий runtime-модуль для `VoiceScenario` (например, `VoiceSynthesizer/src/runtime.ts`).
- Вынести туда подготовку композиции сценариев и общей timeline.
- Вынести интерпретацию `set` и `animate`.
- Вынести вычисление cubic bezier.
- Вынести обновление активных automation и семантику сохранения `to` после окончания `duration`.
- Обеспечить получение фактического `VoiceControlState` во времени или итерацию состояния по временной шкале.
- Перевести `synthesizeScenario` на этот runtime.
- Перевести `ScenarioVisualizer` на тот же runtime, чтобы график был отображением реального состояния синтезатора, а не отдельной интерпретацией сценария.
- Сохранить существующую семантику композиции массивов сценариев: `initial` только у первого сценария, последующие продолжают текущее состояние без reset.

## Критерий результата

Для одного и того же `VoiceScenario` синтезатор и визуализатор используют одну и ту же реализацию state machine. После изменения runtime-семантики невозможно получить ситуацию, когда DSP исполняет сценарий одним образом, а визуализатор отображает его другим.

Устранить дублирование логики исполнения VoiceScenario между synthesizeScenario и ScenarioVisualizer.

Вынести runtime VoiceScenario в общий модуль для синтезатора и визуализатора

## Контекст

Нужно жёстко разделить **основное практическое взаимодействие с продуктом** и **объясняющий/маркетинговый слой**.

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

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

Для этого нужен блог.

## Ключевой технический принцип

**Блог не должен быть отдельной технической сущностью.**

Он должен строиться поверх уже существующих концептов.

Основной механизм различения — поле `type` у концепта.

Нужно заранее проработать и внедрить **справочник типов концептов**, в котором блоговые типы будут иметь единый namespace:

```text
blog:default
blog:article
```

и другие типы, начинающиеся с:

```text
blog:
```

То есть блог — это не отдельная модель данных, а способ классификации, выборки и отображения концептов.

## Что нужно проработать

- определить общую систему `type` для концептов;
- определить namespace `blog:*`;
- решить, какие конкретные типы блога нужны;
- зафиксировать назначение каждого типа;
- определить, какой тип является базовым/дефолтным;
- определить, какие поля концепта используются для блогового отображения;
- определить правила URL/маршрутизации;
- определить правила списка публикаций;
- определить правила отображения отдельной статьи;
- определить, как блоговые концепты связаны с обычными концептами знаний;
- определить, могут ли одни и те же материалы одновременно участвовать в knowledge-структуре и блоге;
- определить фильтрацию по `type`;
- внедрить справочник типов так, чтобы не приходилось размазывать строковые значения по коду;
- предусмотреть дальнейшее расширение типов без изменения модели данных;
- определить SEO-поля и правила для блоговых материалов;
- определить, как формируется индексируемая структура блога;
- определить навигацию по тематике без превращения блога в основной вход в продукт.

## Возможные типы

Стартовые примеры:

```text
blog:default
blog:article
```

Дополнительные типы нужно определить отдельно в рамках задачи. Возможные направления, которые стоит оценить:

- обзор;
- исследование;
- методический материал;
- заметка;
- кейс;
- объяснение принципа;
- SEO-статья.

При этом конкретный список нельзя фиксировать только по привычным CMS-категориям — он должен отражать реальные способы использования контента в проекте.

## Архитектурный принцип

Практический продукт и блог должны существовать независимо друг от друга на уровне пользовательского входа.

Основная логика:

> **продукт отвечает на вопрос «что я могу сделать прямо сейчас?»**
>
> **блог отвечает на вопрос «почему это устроено именно так?»**

Пользователь может долго пользоваться сайтом и вообще не заходить в блог.

Блог нужен для:

- фиксации миссии и принципов;
- объяснения методик;
- публикации исследований и выводов;
- аргументации для родителей и преподавателей;
- SEO;
- накопления публичного знания вокруг проекта;
- формирования доверия;
- объяснения продуктовых решений тем, кому это действительно интересно.

## Ограничение

Не строить блог как центральную маркетинговую воронку перед продуктом.

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

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

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

Внедрить блог

# Задача

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

- **🔊 Динамик** — узнать, как сущность звучит / произносится;
- **? Вопрос** — узнать, что это такое / что это означает.

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

## Зачем это нужно

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

Но нельзя заранее предполагать, что ребёнку известна каждая сущность на сайте. В одном и том же наборе часть картинок может быть знакома, а часть — нет. Также возможны разные состояния знания:

- ребёнок знает объект и его название;
- знает объект, но не знает, как он называется;
- слышал слово, но не знает его значения;
- не знает ни объект, ни его название.

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

## Базовая механика

### Кнопка «Динамик»

На обычной карточке кнопка `🔊` озвучивает текущую сущность или её название.

Пример:

- ребёнок видит картинку тапира;
- нажимает на слово `ТАПИР` или кнопку `🔊`;
- слышит: «тапир».

Это позволяет установить связь между изображением, звучанием и письменной формой даже в том случае, если название раньше было неизвестно.

### Кнопка «?»

Кнопка `?` открывает расширенное состояние **той же карточки**.

В нём сохраняются:

- картинка;
- слово;
- остальные уже существующие элементы карточки;

и дополнительно появляется **короткое текстовое описание сущности**.

Пример:

> Тапир — это крупное животное с коротким хоботком. Он живёт в лесах и хорошо плавает.

Само описание **не должно автоматически проигрываться** при открытии.

Рядом с описанием должна быть отдельная кнопка `🔊`. Кнопки `?` в этом состоянии уже нет, поскольку ребёнок уже открыл объяснение сущности.

## Озвучивание описания

При нажатии на `🔊` рядом с описанием текст озвучивается целиком.

Во время воспроизведения должен идти **синхронный визуальный переход фона / подсветка текста по ходу звучания**.

Задача этого эффекта — показать ребёнку прямое соответствие между звучащей речью и написанным текстом.

Даже если ребёнок ещё не знает, что такое предложение, слово или письменность как система, он начинает наблюдать закономерность:

**звук не возникает сам по себе — он соответствует тому, что написано на экране.**

## Кликабельные слова внутри описания

Каждое отдельное слово в текстовом описании должно быть кликабельным.

По клику слово озвучивается отдельно.

Пример:

Текст:

> Тапир живёт в лесу.

При полном воспроизведении подсветка последовательно проходит по словам:

`Тапир → живёт → в → лесу`

После этого ребёнок может отдельно нажать:

- `живёт` → услышать «живёт»;
- `лесу` → услышать «лесу».

Таким образом ребёнок может самостоятельно заметить, что:

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

Это создаёт естественный переход от текущей механики `слово → слоги → буквы` к более высокому уровню `текст / предложение → слова`, без необходимости предварительно объяснять ребёнку теорию предложения или письменности.

## Общий принцип интерфейса

Механика должна быть универсальной для сущностей сайта:

- `🔊` — **как это звучит / произносится?**
- `?` — **что это такое / что это означает?**

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

Важно не смешивать эти функции: открытие объяснения не должно автоматически запускать длинное аудио, а знание произношения не должно считаться эквивалентом понимания значения.

## Связь с основной задачей

Эта задача является дочерней по отношению к [задаче «Проработать второй уровень освоения письменности: чтение предложений и пунктуация»](/tasks/cmu4sta4y0ldaqw0qjcf497ne).

Механика важна как самостоятельное расширение текущего уровня и как база для дальнейшего освоения более сложных письменных структур.

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

Задачи

Внедрить универсальную механику «Что это?» и озвучивания сущностей

Внедрить блог

Вынести runtime VoiceScenario в общий модуль для синтезатора и визуализатора