Feature/new landing block

.gitignore

@@ -27,7 +27,8 @@ yarn-debug.log*
 yarn-error.log*
 
 # local env files
-.env*.local
+.env*
+!.env.example
 
 # vercel
 .vercel
@@ -50,6 +51,15 @@ skills-lock.json
 /app/.well-known/workflow/
 /.claude/
 /.codex/
+.mcp.json
+/.chrome-debug-profile/
+/.codex-tmp-bin/
+/.impeccable/
 /.swc/
 AGENTS.md
 /docs/product-growth-roadmap.md
+
+# local editor and merge backups
+*.orig
+*.rej
+*.bak

docs/architecture-review.ru.md

@@ -0,0 +1,34 @@
+# Архитектурный аудит кодовой базы
+
+## Выполненный этап
+
+- Telegram-монолит уменьшен с 1005 строк до facade из 38 строк; сценарии разнесены по transport, application и domain
+  границам.
+- Удалены production `any` из Telegram runtime, добавлены Zod contracts и типизированный callback protocol.
+- Выделен общий `src/lib/base-url.ts`, чтобы модуль уведомлений не зависел от 1400-строчного email service ради одной
+  функции.
+- Добавлены application services для подтверждения записи и активации пользователя с внутренней авторизацией и
+  идемпотентностью.
+- Регистрация теперь создаёт Telegram-уведомление администратора с кнопкой `Сделать клиентом`.
+- Новая бронь через бота содержит кнопку `Подтвердить запись`.
+
+## Приоритеты дальнейшей декомпозиции
+
+| Приоритет | Файл | Проблема | Целевая граница |
+| --- | --- | --- | --- |
+| P0 | `src/app/api/admin/events/[id]/route.ts` | route совмещает validation, billing, scheduling, email и Google sync | тонкий HTTP adapter + scheduling commands |
+| P0 | `src/lib/email.ts` | 1400+ строк и несколько каналов/сценариев | email adapter + notification use cases + template data mappers |
+| P1 | `src/modules/payments/financial/financial-service.server.ts` | ledger, pricing, charging, refunds и email outbox в одном сервисе | отдельные financial commands и repositories без изменения ledger-инвариантов |
+| P1 | `src/app/api/actions/dashboard-actions.ts` | admin/client DTO и queries в одном action-файле | dashboard query services по scope |
+| P1 | `src/app/[locale]/(admin)/admin/schedule/_components/event-dialog.tsx` | форма, billing UI и мутации в одном компоненте | RHF form sections + controller hook + explicit create/edit variants |
+| P2 | `src/components/profile-form.tsx` | профиль, auth preferences и integrations смешаны | независимые settings sections с локальным состоянием |
+| P2 | `src/modules/payments/paypal/service.ts` | provider API, mapping и бизнес-операции смешаны | PayPal adapter + payment application service |
+
+## Правило для новых функций
+
+Новый сценарий начинается с application command/query и минимального DTO. Route Handler, Server Action, workflow и
+Telegram handler являются adapters и не дублируют бизнес-мутацию. Доступ проверяется на внешней границе и повторно в
+server-only application service. Внешние эффекты запускаются после успешной транзакции и по возможности через outbox.
+
+Большой файл не делится по формальному количеству строк: границей служит причина изменения. Transport, validation,
+domain policy, persistence и presentation должны меняться независимо и иметь отдельные тесты.

docs/codebase-guidelines.ru.md

@@ -65,9 +65,6 @@
 
 Примеры из проекта:
 
-- `src/app/[locale]/(dashboard)/app/pillo/page.tsx`
-- `src/app/[locale]/(dashboard)/app/pillo/_components/pillo-app-shell.tsx`
-- `src/app/[locale]/(dashboard)/app/pillo/_hooks/use-pillo-tabs.ts`
 - `src/app/[locale]/(dashboard)/my/data/_actions/documents.actions.ts`
 - `src/app/[locale]/(admin)/admin/blog/[id]/_components/blog-editor-form.types.ts`
 
@@ -94,7 +91,6 @@
 
 - `profile-form.tsx`
 - `theme-provider.tsx`
-- `pillo-app-shell.tsx`
 - `admin-payments-table.tsx`
 - `take-confirmation.tsx`
 
@@ -144,7 +140,6 @@
 - `use-heartbeat.ts`
 - `use-push-notifications.ts`
 - `use-user-events.ts`
-- `use-pillo-tabs.ts`
 - `use-blog-editor-lock.ts`
 
 Правило:
@@ -273,7 +268,6 @@ CSS-файлы тоже придерживаются нижнего регист
 
 Примеры:
 
-- `src/app/[locale]/(dashboard)/app/pillo/_components/*`
 - `src/app/[locale]/(dashboard)/my/sessions/_components/*`
 - `src/app/[locale]/(admin)/admin/schedule/_components/*`
 - `src/app/[locale]/(public)/blog/_components/*`
@@ -300,8 +294,6 @@ CSS-файлы тоже придерживаются нижнего регист
 
 Примеры:
 
-- `src/app/[locale]/(dashboard)/app/pillo/_hooks/use-pillo-tabs.ts`
-- `src/app/[locale]/(dashboard)/app/pillo/_hooks/use-pillo-settings-form.ts`
 
 Туда кладём hooks, если они:
 
@@ -393,7 +385,6 @@ CSS-файлы тоже придерживаются нижнего регист
 
 Пример:
 
-- `src/app/[locale]/(dashboard)/app/pillo/_hooks/use-pillo-medication-form.ts`
 
 ### 6.4 Чего не делать
 
@@ -417,7 +408,6 @@ CSS-файлы тоже придерживаются нижнего регист
 - `modules/ai`
 - `modules/backup`
 - `modules/payments`
-- `modules/pillo`
 - `modules/system-logs`
 
 Сюда кладём:
@@ -433,7 +423,6 @@ CSS-файлы тоже придерживаются нижнего регист
 Примеры:
 
 - `src/modules/backup/service.ts`
-- `src/modules/pillo/schedule.ts`
 - `src/modules/payments/factory.ts`
 - `src/modules/system-logs/system-log-service.server.ts`
 
@@ -456,7 +445,6 @@ CSS-файлы тоже придерживаются нижнего регист
 Сравнение:
 
 - `src/lib/safe-url.ts` — общий helper;
-- `src/modules/pillo/schedule.ts` — доменная логика расписания;
 - `src/lib/prisma.ts` — инфраструктурный доступ к Prisma;
 - `src/modules/backup/workflow.ts` — доменная orchestration-логика backup.
 
@@ -529,7 +517,6 @@ CSS-файлы тоже придерживаются нижнего регист
 
 - `blog-editor-form.types.ts`
 - `src/app/[locale]/(admin)/admin/users/_components/types.ts`
-- `src/app/[locale]/(dashboard)/app/pillo/_components/types.ts`
 
 ### 9.2 Общие типы
 
@@ -626,7 +613,6 @@ email-вёрстки структуру или табличную расклад
 - `create-site-backup-workflow.ts`
 - `restore-site-backup-workflow.ts`
 - `session-reminder-workflow.ts`
-- `pillo-intake-reminder-workflow.ts`
 
 Если модуль домена лишь вызывает workflow, адаптер можно держать в домене или `lib`, но точка входа workflow должна оставаться в `src/workflows`.
 
@@ -724,7 +710,6 @@ email-вёрстки структуру или табличную расклад
 Хорошо:
 
 - `use-mobile.tsx`
-- `use-pillo-tabs.ts`
 
 ### Утилиты
 

docs/in-app-notifications.ru.md

@@ -142,10 +142,14 @@ await resolveUserNotificationByKey(userId, systemNotificationKeys.incompleteInta
 
 После первой регистрации также создаётся одноразовое приветственное уведомление:
 
-- `otpRegistration`: регистрация по одноразовому коду, содержит переход к заполнению имени;
+- `otpRegistration`: регистрация по одноразовому коду;
 - `googleRegistration`: регистрация через Google;
+- если имя уже сохранено, приветствие обращается к пользователю по имени и не показывает лишнее действие;
+- если имени нет, приветствие предлагает заполнить его и содержит переход в профиль;
 - оба сценария сообщают, что полный функционал станет доступен после подтверждения учётной записи администратором.
 - каждый активный администратор получает дедуплицированное уведомление о новом аккаунте со ссылкой на управление пользователями.
+- после перевода нового аккаунта из `GUEST` в `USER` все активные уведомления администраторов об этой регистрации
+  автоматически отмечаются прочитанными, а пользователь получает дедуплицированное уведомление об активации.
 
 ## История уведомлений
 

docs/schedule-timezone-guidelines.ru.md

@@ -1,7 +1,7 @@
 # Правила работы с датами и часовыми поясами расписания
 
 Этот документ обязателен для разработчиков и AI-агентов, которые изменяют расписание, консультации, личный кабинет,
-админский календарь, email-уведомления или Pillo.
+админский календарь или email-уведомления.
 
 ## Единая точка истины
 
@@ -68,7 +68,7 @@ const dateTime = useScheduleDateTime(timeZone, locale);
 
 ## Date-only поля
 
-Поля, которые являются бизнес-датой без времени (например, дата окончания курса Pillo), нельзя трактовать как момент
+Поля, которые являются бизнес-датой без времени (например, дата окончания действия документа), нельзя трактовать как момент
 события и бездумно конвертировать в timezone. Нужно сохранить их доменную семантику и использовать явно выбранный
 стабильный timezone/формат через shared-сервис.
 

docs/telegram-bot-architecture.ru.md

@@ -0,0 +1,92 @@
+# Архитектура Telegram-бота
+
+## Цель
+
+Telegram является внешним transport-слоем. Он принимает update, определяет пользовательское действие и вызывает
+server-only application service. Бизнес-правила ролей, расписания, платежей и уведомлений не должны жить в webhook
+route или Telegram API client.
+
+## Структура модуля
+
+```text
+src/modules/telegram/
+├── telegram-service.server.ts       # совместимый публичный facade
+├── telegram-types.ts                # валидируемые transport contracts
+├── telegram-config.server.ts        # конфигурация и webhook secret
+├── telegram-api-client.server.ts    # единственный adapter Telegram Bot API
+├── telegram-account.server.ts       # привязка аккаунта и настройки канала
+├── telegram-broadcast.server.ts     # административные рассылки
+├── telegram-admin-notifications.server.ts
+├── telegram-formatter.ts            # безопасное форматирование HTML-сообщений
+└── bot/
+    ├── callback-data.ts             # публичный callback protocol
+    ├── keyboards.ts                 # reply/inline keyboards
+    ├── webhook-router.server.ts     # registry команд и callbacks
+    └── handlers/                    # один пользовательский сценарий на handler
+```
+
+Бизнес-мутации вынесены за пределы transport-модуля:
+
+- `src/modules/scheduling/booking-approval.server.ts` — атомарное подтверждение обычной заявки, списание оплаты и
+  запуск post-commit уведомлений;
+- `src/modules/users/user-approval.server.ts` — идемпотентный переход `GUEST → USER` и завершение уведомлений
+  администраторов.
+
+## Поток webhook
+
+1. `POST /api/telegram/webhook` проверяет, что бот включён.
+2. Заголовок `x-telegram-bot-api-secret-token` сравнивается через `crypto.timingSafeEqual` до чтения и логирования body.
+3. Update валидируется Zod-схемой как `unknown`.
+4. Router находит command/callback handler в registry.
+5. Handler получает минимальный DTO, проверяет доступ и вызывает application service.
+6. Application service повторно проверяет роль инициатора и выполняет условную/транзакционную мутацию.
+
+## Административные callbacks
+
+Кнопки изменения данных работают только при одновременном выполнении условий:
+
+- `adminChatId` настроен как личный Telegram ID администратора;
+- этот Telegram ID привязан к пользователю сайта;
+- пользователь имеет роль `ADMIN` и не отключён;
+- callback относится к разрешённой операции из typed protocol.
+
+Подтверждение записи использует условный переход `PENDING_CONFIRMATION → SCHEDULED`. Повторное нажатие не выполняет
+повторное списание. Активация пользователя допускает только переход `GUEST → USER`; через callback нельзя назначить
+роль `ADMIN`, активировать отключённый аккаунт или изменить уже существующего администратора.
+
+## Добавление новой команды
+
+1. Добавить handler в `bot/handlers/<action>-command.server.ts`.
+2. Handler должен принимать transport DTO, получать только необходимые поля и проверять статус аккаунта.
+3. Зарегистрировать matcher в `commandHandlers` файла `webhook-router.server.ts`.
+4. Бизнес-мутацию разместить в соответствующем domain/application модуле, а не в handler.
+5. Добавить unit-тест matcher/handler и тест application service.
+
+## Добавление новой callback-кнопки
+
+1. Добавить вариант discriminated union, builder и parser в `bot/callback-data.ts`.
+2. Учитывать ограничение Telegram: `callback_data` не длиннее 64 байт.
+3. Добавить keyboard factory в `bot/keyboards.ts`.
+4. Создать отдельный handler и зарегистрировать его в `callbackHandlers`.
+5. Для административной мутации повторно проверить Telegram ID, роль `ADMIN` и domain-инварианты.
+6. Сделать мутацию идемпотентной через условный `updateMany`, unique key или operation key.
+
+## Эксплуатационные требования
+
+- `AUTH_SECRET` обязателен. Fallback-секретов нет.
+- Подробные payload-логи webhook записываются только при `telegramWebhookLogsEnabled`.
+- Токен бота и webhook secret нельзя помещать в diagnostic payload.
+- Весь динамический текст для HTML parse mode проходит через `escapeTelegramHtml()`.
+- Для дат расписания используется только `createScheduleDateTime()`.
+- Production consumers постепенно переводятся с facade на прямой узкий server-only import; facade сохраняется для
+  обратной совместимости.
+
+## Следующий этап
+
+1. Перевести web-confirmation из `api/admin/events/[id]` на тот же scheduling application service и расширить его для
+   reschedule-заявок. Сейчас Telegram намеренно подтверждает только обычную новую заявку.
+2. Разделить `src/lib/email.ts` на channel adapters и notification use cases. `getBaseUrl()` уже вынесен в независимый
+   `src/lib/base-url.ts`, а Telegram API imports больше не проходят через общий facade.
+3. Добавить persistent outbox для внешних Telegram/Email/Google post-commit эффектов, чтобы временный сбой канала можно
+   было повторить без повторения бизнес-мутации.
+4. Добавить audit event с actor ID для всех административных Telegram-команд.