Перейти к содержанию

План реализации SKUARO

Решение 0032 меняет способ выполнения этого плана: обычные изменения сразу размещаются текущим snapshot в STAGE после минимальной сборки/запуска. Полные gates, hash/merge candidate и независимая проверка выполняются только отдельной командой или перед PROD. Решение 0033 снимает функциональные ограничения раннего MVP. Решение 0034 требует production-like поведения STAGE: без test-only accounts, bypass, mocks или закрытия регистрации из-за среды.

Статус: ПРИНЯТ; ФАЗА 1B ВЫПОЛНЕНА

Обновлено: 2026-08-25.

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

Фаза 0 — архитектурная фиксация

Статус: ВЫПОЛНЕНО.

Результат:

  • каноническая архитектура и модель данных записаны в проект;
  • прежние отсрочки backend заменены целевой архитектурой;
  • зафиксированы домены, среды, релизы и границы репозиториев;
  • сохранён продуктовый контрольный этап из пяти пользовательских проверок.
  • зафиксированы общая память агентов, жизненный цикл project Skills и доказательный gate перед handoff.
  • созданы шесть project-scoped профилей и безопасная последовательность orchestrator → executor → tester/reviewer → handoff.

Фаза не включает код, зависимости, сервер, DNS, deploy, commit или push.

Фаза 1 — продуктовая проверка и локальная техническая подготовка

Два потока можно вести параллельно.

1A. Проверка сценария «Сегодня»

Статус: ПОДТВЕРЖДЕНО ПОЛЬЗОВАТЕЛЕМ 2026-08-21.

Владелец проекта объявил итог ПОДТВЕРЖДЕНО. Карточки участников и измерения критериев в репозитории не зафиксированы; их наличие не выводится автоматически из итогового статуса.

  1. Выбрать первые пять участников по docs/MVP_VALIDATION_PLAN.md.
  2. Провести встречи без реальных клиентских данных.
  3. Записать обезличенные результаты.
  4. Выбрать: ПОДТВЕРЖДЕНО, НУЖНА ИТЕРАЦИЯ или НЕ ПОДТВЕРЖДЕНО.

Только ПОДТВЕРЖДЕНО разрешает реализацию полного вертикального backend-сценария.

1B. Локальная основа без широкой бизнес-логики

Статус: ВЫПОЛНЕНО 2026-08-21.

После отдельного подтверждения установки зависимостей:

  • зафиксировать Node.js 24 и воспроизводимые версии инструментов;
  • добавить router/providers/runtime config во frontend;
  • подготовить apps/api, apps/worker, packages/contracts, packages/database, packages/config, packages/testing;
  • добавить health endpoints, OpenAPI generation и тестовый PostgreSQL;
  • подготовить Docker Compose и CI checks;
  • сохранить текущую визуальную систему и Playwright baseline.

До результата 1A не создаются широкие продуктовые модули, интеграции и AI-функции.

Фактический результат 1B:

  • Node.js 24/npm 11 и Docker Desktop установлены и проверены; точная фиксация patch-версий Node.js/npm позднее отменена владельцем;
  • созданы все перечисленные workspace и технические границы;
  • добавлены liveness/readiness, OpenAPI и generated fetch-client;
  • PostgreSQL 18.4-bookworm закреплён по digest и проверен реальным Drizzle-запросом;
  • добавлены unit/component/API, behavioral E2E, прежние visual tests и CI workflow;
  • бизнес-таблицы, auth, интеграции, AI и реальные данные не добавлялись.

Фаза 2 — подготовка внешних контуров

Статус: ЧАСТИЧНО ВЫПОЛНЕНО 2026-08-21. Server env прочитан по отдельному разрешению без вывода значений; server/DNS audit и план отката выполнены. Site/Docs репозитории не создавались.

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

  1. Создать приватные webuzateam/SkuAro-Site и webuzateam/SkuAro-Docs.
  2. Подготовить в Docs-репозитории независимые Material for MkDocs projects user-docs и dev-docs, а также общие overrides/assets.
  3. Получить разрешение прочитать только /Users/alexzandr/MEGA/____SECRETS/config_server-skuaro_top.env без вывода значений.
  4. Провести read-only аудит тестового сервера: ОС, CPU/RAM/disk, Docker, открытые порты, firewall, proxy, TLS, существующие сервисы и backup.
  5. Отдельно проверить фактические DNS-записи доменов.
  6. Представить план изменений и отката до мутаций сервера или DNS.

Фаза 3 — DEV и developer docs

Статус: DEV ПРОДУКТА ЗАПУЩЕН 2026-08-21; DEVELOPER DOCS ОЖИДАЮТ ОТДЕЛЬНЫЙ РЕПОЗИТОРИЙ.

После отдельного разрешения на server/DNS/deploy:

  • развернуть изолированный Compose project skuaro-dev;
  • опубликовать текущий прототип на dev.skuaro.top;
  • опубликовать developer docs в отдельном контуре на dev-doc.skuaro.top;
  • включить HTTPS и noindex; Basic Auth не применять ни к одному test-origin без нового прямого запроса владельца, а Product-маршруты защищать SKUARO Auth и backend permissions;
  • добавить runtime config, health checks, log rotation и backup перед рискованными изменениями;
  • выполнить внешние smoke tests без реальных клиентских данных.

Фаза 4 — вертикальный MVP-сценарий

Условие входа: результат проверки «Сегодня» — ПОДТВЕРЖДЕНО.

Статус: УСЛОВИЕ ВХОДА ВЫПОЛНЕНО; МОДУЛЬНЫЕ ГРАНИЦЫ И AUTHORIZATION CONTOUR СОЗДАНЫ; ЛОКАЛЬНЫЕ APPSHELL И HOME ПРИНЯТЫ ДЛЯ HANDOFF; AUTH POC В РАБОТЕ.

Порядок:

  1. Выполнено 2026-08-22. Применено решение 0014: создан modules/today, фактические общие Auth/Admin/Account capabilities вынесены в platform/, email adapter — в integrations/email; настроены public entrypoints и автоматическая проверка запрещённых импортов и циклов. Не существующие в коде organization/access реализации заранее не создавались.
  2. Auth PoC: открытая регистрация, подтверждение email до создания организации, email/password, recovery, PostgreSQL sessions, revoke и блокировка inactive. Код, migration job, frontend/backend access contract, route guards, SuperAdmin bootstrap, Gmail sender и синтетическая PostgreSQL integration готовы и развёрнуты в DEV. Решением 0025 локально добавлен Resend HTTPS transport на 443 без новой зависимости; Gmail сохранён как fallback. Product и developer API docs открыты без Basic Auth по решению 0030; защищённые Product-маршруты используют SKUARO Auth. Resend account и sending domain mail.skuaro.top созданы, DNS опубликован, домен получил Verified, минимальный API key сохранён во внешнем secret-file, а контролируемое письмо через локальный adapter получило Delivered и подтверждено владельцем. DEV deploy и полный sign-up → email verify → login ещё не выполнены; preflight candidate 0ddd04d остановлен до защиты verification token в API/edge logs. Решением 0026 принята единая production-ready Auth log policy для всех Product App runtime; локальная реализация проходит evidence gate и должна быть перенесена с legacy skuaro.top на lk.skuaro.top при миграции решения 0019. Продуктовое требование подтверждения email не отменено; ручное подтверждение пользователя из Admin и post-verification организация ещё не готовы.
  3. Выполнено локально и принято для handoff 2026-08-24. Реализованы platform/shell и platform/home: общий AppShell, зоны S1–S3/P1–P6/O1–O3, /home, redirects settings и разделение глобальной оболочки с содержимым modules/today. Используются только подтверждённые access-данные и синтетические явно помеченные сводки; deploy не выполнялся.
  4. Заблокировано владельцем до успешного live email gate. Решение 0024 с transport-уточнением 0025: после настройки Resend DEV, контролируемого письма и полного sign-up → email verify → login реализовать schema и backend onboarding POST /api/v1/organization для атомарных Organization, Membership(owner), OrganizationModule(today), AuditEvent и OutboxMessage; затем отдельными срезами Client, Request, NextAction и полный модульный доступ. Frontend /onboarding/organization подключается только после доказанного backend-контракта. Обход email verification не допускается.
  5. Tenant isolation и audit/outbox constraints.
  6. Транзакционный /api/v1/intake.
  7. /api/v1/today и завершение следующего действия.
  8. Подключение текущего frontend к реальному API без визуальной переработки бизнес-области «Сегодня».
  9. /settings/profile и /settings/security реализованы локально в первом frontend-срезе; разрешённые /organization/settings/* добавить на общем каркасе только после появления соответствующих данных и permissions.
  10. Unit, integration, migration, tenant/concurrency и E2E tests, включая маршрутизацию после входа, контексты и запрет tenant-data leakage.

Личный кабинет разделяется на /settings/profile и /settings/security, но первоначально может быть ограничен email и безопасной сменой пароля. Настройки организации живут в /organization/settings/* и не смешиваются с аккаунтом. /admin получает разделы «Администраторы» и «Пользователи» по матрице платформенных прав; изменение email, пароля, роли и статуса обязательно проходит серверную авторизацию и аудит. Backend отдельно проверяет запрет platform_admin изменять учётные записи или назначение роли super_admin. Ручное подтверждение пользователя без email доступно только super_admin, требует причины и открывает тот же отдельный organization onboarding; tenant-контекст не создаётся самим подтверждением. Матрица остальных ролей утверждается до их реализации.

Модуль today является первым продуктовым модулем. Вертикальный срез должен отделять его module entitlement и permissions от технических модулей организаций, клиентов, обращений и действий, даже если первый тариф временно включает только today.

Переход к публичному Auth-контуру DEV выполнен по решению 0016 после route/API guards, 401/403, inactive/session revoke и anti-abuse tests. Tenant/module isolation для обычных пользователей пока обеспечивается fail-closed: /today откроется после реализации Organization, Membership, entitlement и permissions. STAGE не менялся.

Первый вертикальный срез считается готовым только после проверки атомарности intake, tenant isolation, восстановления миграций и пользовательского E2E.

Отдельный реестр email неподтверждённых регистраций и письма о продолжении регистрации не входят в этот срез до решения consent, retention, удаления, частоты отправки и anti-abuse.

Фаза 4B — модульный доступ и упаковка

Условие входа: подтверждённый и работающий вертикальный срез today.

  1. Создать реестр продуктовых модулей с первым идентификатором today.
  2. Добавить подключённые организации модули и доступ membership к модулю.
  3. Утвердить permissions today для ролей организации.
  4. Добавить руководителю просмотр активных модулей и управление доступом сотрудников.
  5. Определить первые тарифные пакеты и их связь с модулями без подключения оплаты.
  6. Отдельно выбрать billing provider и правила жизненного цикла подписки до реальных платежей.

Фаза 5 — STAGE

Статус: ТЕХНИЧЕСКИЙ STAGE ПРОТОТИПА ЗАПУЩЕН НА ПРЕЖНЕЙ ДОМЕННОЙ СХЕМЕ И ЗАМОРОЖЕН. По указанию владельца текущая разработка обновляет только DEV: STAGE остаётся на worktree-3d10591aed41, DEV — на worktree-9f9113f60287. БД, volume, credentials, networks и runtime config разделены; новая схема решения 0019, продвижение изменений и migration/restore gate требуют отдельных действий.

  • развернуть отдельный Compose project skuaro-stage на тестовом сервере;
  • использовать отдельные БД, volume, credentials, cookies и test-only данные;
  • зафиксировать точный candidate commit, сборку и фактически использованные image ID или иной идентификатор развертывания;
  • присвоить candidate metadata YY.MM.DD.NN-rc;
  • выполнить migration, health, smoke, E2E и restore checks;
  • опубликовать Site на skuaro.top, App на lk.skuaro.top, user docs на doc.skuaro.top без Basic Auth и с noindex;
  • разрешить на ветке и сервере STAGE исходники, тесты, миграции и служебные файлы, необходимые для сборки, диагностики и оценки, без секретов и реальных клиентских данных.
  • разделить CI на gates G1–G12 по docs/STAGE_TESTING_STRATEGY.md, настроить изолированные test databases и отдельные отчёты;
  • создать защищённую ветку STAGE, GitHub Environment и минимальный deploy-доступ;
  • после контролируемого первого запуска отметить pipeline как АКТИВИРОВАНО в docs/STATUS.md.

До активации pipeline продвижение и deploy требуют отдельных разрешений. После активации разрешённый merge DEV -> STAGE автоматически запускает deploy соответствующего контура без второго подтверждения. Незавершённое состояние DEV и любой обязательный FAIL/BLOCKED блокируют merge или deploy.

Фаза 6 — production

Production готовится отдельным проектом на отдельном сервере:

  • skuaro.com — лендинг;
  • lk.skuaro.com — приложение;
  • doc.skuaro.com — пользовательская документация;
  • www.skuaro.com — redirect на skuaro.com.

В PROD продвигается тот же digest, который прошёл STAGE. После ручного STAGE-тестирования владелец отдельно запускает ПОДГОТОВИТЬ К ПРОДАКШНУ по docs/PRODUCTION_READINESS.md; требуются независимый GO, backup, migration plan, health/smoke checks и проверяемый rollback. Даже GO не выполняет deploy: фактическое размещение требует отдельной явной команды владельца на конкретный PROD deploy. Формальная версия YY.MM.DD.NN относится только к lk.skuaro.com.

Отдельные контрольные разрешения

Действие Требование
Установка или обновление зависимостей объяснение состава и отдельное подтверждение
Создание Site/Docs репозиториев отдельное разрешение на внешнее действие
Чтение server env-файла отдельное разрешение; значения не выводятся
Изменение сервера или DNS план, откат и отдельное разрешение
Deploy DEV, STAGE или PROD отдельное разрешение для каждого контура
Merge/PR/продвижение веток отдельное разрешение
Commit/push только по действующей Git-политике