Audio Scribe TMA: workspace, где транскрибация стала одним из входов

Audio Scribe TMA — frontend-часть Audio Scribe на React/Vite: Telegram Mini App и web workspace. Это тот экран, который нужен, когда расшифровка уже перестаёт быть одноразовым ответом в чате и превращается в рабочий материал: её надо открыть, перечитать, разложить, связать с задачами и не потерять в потоке сообщений.

Сначала TMA было удобно описывать как интерфейс вокруг транскрибации. Сейчас это уже узко: workspace стал task-manager-first, а расшифровка превратилась в один из способов принести материал в работу.

На практике сценарий выглядит так: пользователь расшифровывает встречу, сохраняет результат в Files, выделяет заметки, превращает follow-up в задачи, связывает их с календарём и ставит напоминания. Но начать можно и не с аудио — с задачи, заметки, файла, календарного пункта или напоминания. В этом и есть роль TMA: не заменить бота, а дать место, где из входящих материалов получается понятный следующий шаг.

Вход и авторизация

TMA поддерживает два сценария:

Telegram Mini App — при запуске внутри Telegram используется initData;
web-flow — для обычного web-доступа используется JWT.

Telegram initData имеет приоритет над JWT. Для Mini App это принципиально: человек открывает workspace из Telegram и продолжает работу с тем же аккаунтом, балансом и материалами, а не попадает в отдельную параллельную сессию.

Основные routes

Текущий route-контур выглядит так:

/workspace — landing в task-manager-first рабочую область: задачи, календарный state и основные рабочие действия;
/workspace/transcribe — отдельный экран загрузки и транскрибации;
/workspace/files — список Files;
/workspace/files/:id — детальная карточка файла или результата;
/workspace/notes — заметки;
/workspace/reminders — напоминания, если route доступен при текущих feature flags и UI guards;
/workspace/settings — настройки;
/workspace/more — дополнительные действия и разделы.

Mobile-навигация тоже отражает новый центр продукта: Задачи, Календарь через query state, Библиотека/Files, Ещё. Это важный сдвиг в ощущении продукта: пользователь открывает не «ещё одну кнопку для загрузки аудио», а рабочее пространство, где транскрибация остаётся доступной, но как secondary flow, а не как единственная точка входа.

Dashboard-embedded transcribe mode

Транскрибация никуда не исчезла. В /workspace/transcribe можно загрузить аудио или видео, выбрать параметры и отправить файл в обработку.

Обычно здесь важны:

язык;
пунктуация и регистр;
speaker labels;
profanity filter;
entity detection;
redact PII;
polling статуса для больших файлов.

Этот flow лучше подходит для больших записей, чем Telegram-чат: пользователь видит экран загрузки, параметры и статус обработки, а не пытается управлять длинным файлом через переписку. Но после обработки материал не должен оставаться только «результатом транскрибации» — он может стать файлом, заметкой, задачей или контекстом для последующих вопросов.

Files: пользователю — «Файлы», backend — artifacts

В пользовательском интерфейсе правильнее говорить Files или Файлы. Это библиотека рабочих материалов: загруженные файлы, результаты обработки, превью, скачивание, удаление, повторное открытие и переход к связанным данным.

При этом backend/API/domain ещё использует термин artifacts. Поэтому в коде и API встречаются artifacts routes:

list/detail;
upload;
download;
preview;
delete.

Для пользователя это не должно звучать как «артефакты». Ему важнее понимать, где лежит запись, результат обработки, превью или документ, к которому можно вернуться позже. Поэтому в статье и интерфейсе логичнее держать человеческое название «Файлы», а техническую терминологию упоминать только там, где важно объяснить архитектуру.

Document workflows

Поверх Files есть document workflows: generate/transform через единый create document-runs endpoint с workflowType. Это не нужно описывать через старые workspace document-runs routes как текущий интерфейс.

Смысл простой: файл или сохранённый материал может стать входом для генерации или преобразования документа. Так TMA закрывает промежуток между «у меня есть текст» и «с этим текстом можно работать дальше». Например, расшифровку можно превратить в структурированную заметку, черновик, выжимку или другой рабочий формат — в зависимости от доступных workflow и настроек.

Notes

Notes живут как web/API surface при notesEnabled + notesWebEnabled. Если флаги включены, пользователь может:

смотреть список заметок;
создавать и редактировать заметки;
удалять;
закреплять;
архивировать;
работать с тегами;
добавлять attachments;
связывать заметки с рабочими материалами.

Заметки нужны как промежуточный слой между «сырой расшифровкой» и «задачей». Не всё из встречи сразу становится action item. Иногда сначала нужно сохранить мысль, цитату, наблюдение или кусок контекста — то, что легко потерять в transcript, но рано превращать в задачу.

Tasks и Calendar

Главное изменение workspace — фокус на задачах и календаре. TasksPage стала landing-экраном для /workspace, а не дополнительным разделом где-то рядом с транскрибацией.

Поддерживаются разные представления и действия:

board;
list;
calendar;
week/day;
projects;
subtasks;
bulk actions;
task-calendar links;
unified schedule.

Практический сценарий после созвона выглядит так:

Запись расшифровали через бота или /workspace/transcribe.
Результат сохранился в Files.
Важные мысли ушли в заметки.
Follow-up превратился в задачи.
Задачи связались с проектом, датами и календарём.
Для критичных пунктов добавились напоминания.

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

Reminders

Reminders покрывают one-shot и recurring-сценарии. В зависимости от включённых флагов и UI guards доступны:

создание и редактирование напоминаний;
pause/resume/cancel;
snooze;
recurring reminders;
категории;
delivery через Telegram;
delivery через ntfy;
web/inline/polling элементы управления.

Важно: route /workspace/reminders есть в code path, но конкретная доступность в production зависит от feature flags. Поэтому лучше писать честно: слой есть, но часть web- и inline-возможностей может быть скрыта операторскими настройками.

Settings и More

/workspace/settings нужен для пользовательских настроек, баланса, профиля и интерфейсных параметров. /workspace/more собирает дополнительные разделы и действия, которые не должны перегружать нижнюю mobile-навигацию.

Это особенно важно для TMA: экран маленький, а сценариев много, поэтому не каждый рабочий сценарий должен быть top-level вкладкой. Часть функций лучше держать рядом, но не заставлять пользователя каждый раз пробираться через перегруженную навигацию.

Admin dashboard

Кроме пользовательского workspace, frontend содержит gated admin surface. Он не должен затмевать основной пользовательский сценарий, но является важной частью реального продукта.

В admin dashboard есть разделы вроде:

Overview;
Transcribe;
Tasks;
Reminders;
Users;
Servers;
Audit;
Agent;
Memory;
Settings.

Часть пунктов зависит от feature flags и operator-managed настроек. Это нормальный внутренний слой: посмотреть состояние, проверить пользователей и серверы, отследить операции, управлять flags, agent/workflow и memory-разделами.

Чем TMA отличается от бота

Бот удобен для входа: быстро отправить материал, вопрос или получить уведомление. TMA удобнее, когда нужно разложить результат по полкам:

открыть Files и вернуться к материалу;
просмотреть или преобразовать документ;
создать заметку;
выделить задачи;
посмотреть календарь;
настроить напоминания;
проверить баланс и параметры;
работать с большим файлом через UI.

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

Ограничения

Не все возможности одинаково видны в production. В проекте много feature flags: часть включена по умолчанию, часть fail-closed или operator-managed. Поэтому корректнее говорить не «всё всегда доступно всем», а «в коде и продуктовой модели есть такие слои, их видимость зависит от настроек».

Отдельные планы развития — targeted refactoring roadmap и TMA UX/UI improvement plan. То есть интерфейс уже рабочий, но его структура и удобство продолжают меняться: для такого workspace это нормальная часть развития, потому что он соединяет несколько пользовательских путей, а не один изолированный экран.

Это описание TMA/workspace-части Audio Scribe: без заявлений о точности, SLA или production-нагрузке, с акцентом на реальные routes, feature flags и текущий task-manager-first фокус — то есть на место, где материалы после расшифровки превращаются в дальнейшую работу.

Audio Scribe TMA