Документация: этапы по фазам, решения D-026…D-033

- Новый порядок этапов (D-026): фаза 1 — концепт на dev без внешних
  сервисов (1b сайт, 1c вход, 1d ключи, 1e счёт и демо-оплата,
  1f демо-выдача, 1g продления, 1h рефералы); фаза 2 — Telegram;
  фаза 3 — ALTCHA, ЮKassa, почта, Twenty, Chatwoot, Umami, выдача
  через API и публичный запуск; фаза 4 — звёзды и эквайринги.
- Решения: демо-оплата по списку IP (D-027), выдача ключей через
  адаптер manual/demo/api (D-028), страницы сайта из блоков Payload
  (D-029), пересборка через revalidatePath (D-030), RU-адрес у mass
  (D-031), счётчик свободных серверов (D-032), переводы на 5 языков
  в каждом этапе (D-033).
- Тексты описывают работающий продукт; Вейликс — выделенный IP на
  общем сервере; Telegram поддержки — @veilix_support; сроки ответа
  не обещаем; VPN-серверы не ведут журналов.
- Ссылки на этапы во всех документах, Q-12 решён (ЮKassa для RUB),
  R-19 (библиотеки для headless Chromium) сделано.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/02-architecture.md

@@ -16,9 +16,9 @@
 | Vitest | 5.x | модульные тесты |
 | next-intl | 4.x | переводы интерфейса, префиксы языков в URL |
 | Nodemailer | через `@payloadcms/email-nodemailer` | транспорты SMTP, sendmail, «только журнал» |
-| ALTCHA | 3.x | капча без третьих сторон |
-| grammY | 1.x | Telegram-боты, этап 3 |
-| Stripe SDK | актуальный | этап 4 |
+| ALTCHA | 3.x | капча без третьих сторон, этап 3a |
+| grammY | 1.x | Telegram-боты, этапы 2a–2c |
+| Stripe SDK | актуальный | этап 4b |
 
 Точные версии закреплены в `package.json`: на этапе 1a — Next 16.4.2, Payload 3.91.0, React 19.3.1, next-intl 4.14.9, Tailwind 4.3.3, pnpm 12.14. На старте 1a Payload 4 был в бете (4.0.0-beta.3), поэтому начали на 3.91 ([D-002](decisions/D-002-payload-version.md)). Телеметрия Next.js и Payload выключена.
 
@@ -47,14 +47,14 @@ src/
     (front)/m/[host]/[locale]/[currency]/(site)/…  — маркетинговые сайты
     (front)/c/[host]/[locale]/(shell)/…            — кабинет с навигацией
     (front)/c/[host]/[locale]/(plain)/…            — вход и оформление заказа
-    (front)/t/[host]/…                             — MiniApp (этап 3)
+    (front)/t/[host]/…                             — MiniApp (этап 2a)
     (front)/context.ts      — домен, язык и валюта страницы, данные оболочек
     svc/…                   — свои эндпоинты: health, internal/domains; дальше ALTCHA, вебхуки
   payload/
     collections/  access/  fields/  hooks/  components/
   core/                     — бизнес-логика без привязки к UI
     sites.ts  domains/  routing/  currencies/  payments/   — этап 1a
-    billing/  keys/  auth/  referral/  email/  geo/        — следующие этапы
+    billing/  keys/  provisioning/  auth/  referral/  email/  geo/  — следующие этапы
   brands/
     dedicated/  mass/       — различия брендов; страницы и компоненты — с этапа 1b
   ui/                       — общие компоненты: оболочки сайта и кабинета, переключатели, тема, логотип, иконки
@@ -67,7 +67,7 @@ scripts/                    — служебные скрипты (очистк
 
 Корневые layout сайта и кабинета дают только документ: `<html>` с `lang`, `data-site` и скриптом темы. Шапка, подвал и навигация — во вложенных группах `(site)`, `(shell)` и `(plain)`.
 
-Бизнес-логика живёт в `core/` и вызывается одинаково из хуков Payload, server actions, вебхуков, фоновых задач и (на этапе 3) бота.
+Бизнес-логика живёт в `core/` и вызывается одинаково из хуков Payload, server actions, вебхуков, фоновых задач и (с этапа 2b) бота.
 
 ## 4. Окружения
 
@@ -89,8 +89,8 @@ scripts/                    — служебные скрипты (очистк
 
 ## 5. Выкладка в prod
 
-1. В dev: изменения схемы оформляются миграцией (`payload migrate:create`), коммит, push в Gitea, тег релиза. До первой выкладки (этап 1h) миграции не накапливаем: перед ней создаём одну начальную по итоговой схеме. Механизм проверен на этапе 1a: миграция, применённая к пустой схеме, создаёт те же таблицы, что push в dev.
-2. Выкладка — команда `deploy <тег>` пользователя vx_prod, появится на этапе 1h. Запускает её пользователь; по желанию — sudo-правило, разрешающее vx_dev запускать только эту команду (Q-18). Шаги:
+1. В dev: изменения схемы оформляются миграцией (`payload migrate:create`), коммит, push в Gitea, тег релиза. До первой выкладки (этап 3h) миграции не накапливаем: перед ней создаём одну начальную по итоговой схеме. Механизм проверен на этапе 1a: миграция, применённая к пустой схеме, создаёт те же таблицы, что push в dev.
+2. Выкладка — команда `deploy <тег>` пользователя vx_prod, появится на этапе 3h. Запускает её пользователь; по желанию — sudo-правило, разрешающее vx_dev запускать только эту команду (Q-18). Шаги:
    a. взять тег из Gitea (у vx_prod ключ только на чтение) в новую папку `releases/<дата-тег>`;
    b. `pnpm install --frozen-lockfile` и `pnpm build`; ссылки на `shared/.env` и `shared/media`;
    c. применить миграции к `veilix_prod`;
@@ -102,7 +102,7 @@ scripts/                    — служебные скрипты (очистк
 ## 6. Рендеринг и кэширование
 
 1. Маркетинговые страницы собираются статически в вариантах «домен × язык × валюта» при первом запросе (ISR) и кэшируются. Proxy выбирает вариант по префиксу языка и cookie валюты.
-2. Изменение в админке (цена, статус локации, FAQ) вызывает хук Payload, и Next.js пересобирает затронутые страницы за секунды (on-demand revalidation по тегам). Запасной вариант — плановое обновление раз в 5 минут.
+2. Изменение в админке (цена, статус локации, FAQ, текст страницы) вызывает хук Payload, и Next.js пересобирает маркетинговые страницы при следующем заходе (`revalidatePath`, [D-030](decisions/D-030-revalidate-path.md)). Запасной вариант — плановое обновление раз в 5 минут.
 3. При оформлении заказа наличие и цена проверяются заново на сервере. Устаревшая страница не может продать то, чего нет.
 4. Кабинет рендерится на сервере (SSR) для каждого запроса, без кэша.
 5. Маркетинговые домены не ставят cookies, кроме выбора языка, валюты и темы.