Внутренний портал

Roadmap, инженерный план и вся рабочая markdown-документация в одном месте

Портал читает канонические markdown-документы напрямую из проектного дерева `qadam-core`: основной каталог `docs`, связанные спеки и внутренние guide-файлы по относительным ссылкам. Загруженные материалы хранятся отдельно, а комментарии привязаны к каждому документу.

Сейчас в библиотеке видно 104 активных документов. Отдельно скрыто 10 архивных файлов, а основной рост библиотеки сейчас дают 61 внутренних документов блока `docs/Agents`.

Для frontend-команды сейчас опубликовано 19 готовых backend-пакетов, которые нужно внедрять через contract layer и changelog.

Отдельно в remediation backlog сейчас 2 критичных красных зон `qadam-web`, которые мешают закрыть `CP-103`.

Задачи для frontend Смотреть roadmap Открыть библиотеку

Сводка

104

Видно сейчас

Архивных скрыто

Комментариев

Канонические docs

Внутренние Agents

Загруженные файлы

Готово для frontend

Frontend в работе

Frontend подтвердил

Критичных красных зон

Базовые документы

Канонический roadmap

docs/project/roadmap.md

Текущее состояние проекта

docs/project/current-state.md

Заключение по стеку

docs/architecture/stack-assessment-2026-03-27.md

Frontend sync

Что сейчас должна сделать frontend-команда

Этот блок собирается автоматически из docs/frontend/frontend-change-log.md. Здесь показываются только пакеты со статусом ready_for_frontend, то есть backend уже готов и задача должна переходить в работу на стороне frontend.

Полный frontend changelog Открыть frontend handoff Открыть remediation backlog

FE-BE-2026-04-06-01

Refresh cookie `qadam_rt` переведена на root path для server-side refresh

Готово для frontendНет ответа

web auth stability, full page reload after access token expiry, proxy refresh behavior

Endpoint’ов

Задач

Acceptance

Что сделать

Никакой новой интеграции не требуется
Перестать считать logout after reload через ~15 минут “известным ограничением backend”
При проверке stage/prod сценариев отдельно подтвердить: full page reload после истечения access token больше не должен выбрасывать пользователя на /login, если refresh token ещё жив

Подтверждение от frontend

После того как пакет взят в работу или закрыт на стороне frontend, команда должна отметить это здесь. Это не меняет backend changelog, а только фиксирует обратную связь по внедрению.

Migration note

Для уже существующих браузерных сессий, выпущенных до фикса, может понадобиться один новый login, потому что legacy refresh-cookie с path=/api/v1/auth уже была выдана ранее
Требуется действие frontend: нет

FE-BE-2026-04-02-05

Owner-facing status-change notifications включены для seller staff flow

Готово для frontendНет ответа

seller notification settings copy, seller/staff leads UX, operational expectations around owner alerts

Endpoint’ов

Задач

Acceptance

Что сделать

Не считать notifyStatusChangeTelegram purely informational toggle: на окружениях с включённым seller notifications runtime он уже управляет live owner-facing уведомлениями для staff-driven status changes
Если в seller/staff UX есть текст, будто status-change alerts "появятся позже", обновить его под фактическое поведение backend

Подтверждение от frontend

Migration note

Это изменение поведения доставки без расширения публичного API-контракта
Требуется действие frontend: нет

FE-BE-2026-04-02-04

Seller email fallback подготовлен на backend

Готово для frontendНет ответа

seller notification settings copy, operational expectations around email channel

Endpoint’ов

Задач

Acceptance

Что сделать

Не считать notifyNewLeadEmail purely forward-compatible флагом на окружениях, где backend подтвердил SMTP runtime
Если в UI есть жёсткий текст "email ещё не работает", убрать его только после подтверждения, что конкретный target runtime уже получил SMTP_* конфиг
Показывать sellerEmail как фактический email-адрес доставки, а не только как account email из auth-контекста

Подтверждение от frontend

Migration note

Migration касается поведения доставки, а не формы API-ответа
Требуется действие frontend: нет

FE-BE-2026-04-02-03

Seller Telegram onboarding bot flow подготовлен для frontend

Готово для frontendНет ответа

seller notifications UX, Telegram connect/disconnect CTA, onboarding follow-up

Endpoint’ов

Задач

Acceptance

Что сделать

Добавить CTA/кнопку подключения Telegram через GET /seller/telegram/connect-link
Открывать connectUrl как внешний переход в Telegram, а не через локальную строковую сборку bot URL
На verify/disconnect корректно обрабатывать ALREADY_VERIFIED и NOT_CONNECTED как продуктовые состояния, а не как generic error
Синхронизировать seller notification settings screen с новым connect flow, чтобы telegramConnected и telegramUsername обновлялись после успешной привязки

Подтверждение от frontend

Migration note

Это расширение существующего Telegram flow; старые settings endpoints не ломаются
Frontend больше не должен считать, что seller сам знает, где взять verification code: source-of-truth теперь GET /seller/telegram/connect-link
Требуется действие frontend: да

FE-BE-2026-04-02-02

Seller notifications baseline подготовлен для frontend

Готово для frontendНет ответа

seller settings page, lead notification preferences, seller onboarding follow-up

Endpoint’ов

Задач

Acceptance

Что сделать

Добавить экран или секцию seller notification settings на GET/PATCH /seller/notification-settings
Показывать состояние Telegram binding по telegramConnected и telegramUsername, а не по локальным эвристикам
Не обещать пользователю живой email delivery, пока backend отдельно не подтвердит SMTP/provider package
Использовать sellerEmail только как read-only operational hint в настройках, а не как отдельный источник истины о seller profile

Подтверждение от frontend

Migration note

Это новый settings surface; существующие seller profile и lead flows не ломаются
Email toggle уже появляется в контракте, но не означает, что email-канал backend уже доведён до production delivery
Требуется действие frontend: да

FE-BE-2026-04-02-01

Auth contract получил change-password из кабинета

Готово для frontendНет ответа

buyer/seller account settings, password settings form, auth security UX

Endpoint’ов

Задач

Acceptance

Что сделать

Добавить форму смены пароля в buyer/seller кабинете на POST /auth/change-password
Валидировать newPassword по тем же правилам, что и registration/reset-password
Показать отдельное UX-сообщение для неверного текущего пароля вместо generic error toast
После успешной смены пароля корректно показать success-state и быть готовыми к тому, что старые refresh-сессии на других устройствах больше невалидны

Подтверждение от frontend

Migration note

Это новый endpoint, а не замена forgot-password / reset-password
Сброс пароля по коду и смена пароля из авторизованного кабинета теперь должны сосуществовать как два разных UX-потока
Требуется действие frontend: да

FE-BE-2026-03-31-03

Public seller profile начал отдавать backend-generated SEO metadata

Готово для frontendНет ответа

public seller profile SSR page и metadata layer должны перейти с ad-hoc сборки SEO на backend-generated contract

Endpoint’ов

Задач

Acceptance

Что сделать

Перевести public seller page metadata на backend-generated seo block вместо локальной ad-hoc сборки
Использовать seo.canonicalUrl, seo.openGraph и seo.jsonLd как канонический источник для SSR metadata и structured data
Не предполагать, что hidden seller addresses приходят в payload: если массив addresses пуст, секция не должна рендериться
Обрабатывать 404 как нормальный SEO-safe сценарий для non-active / missing seller profile

Подтверждение от frontend

Migration note

Это не просто cosmetic addition: contract public seller profile стал более строгим и более пригодным для SSR/SEO
Frontend не должен опираться на скрытые seller-only поля, если они раньше случайно приезжали в response
Требуется действие frontend: да

FE-BE-2026-03-31-02

Seller review surface и complaint-driven moderation готовы для frontend

Готово для frontendНет ответа

seller review dashboard, seller reply/complaint UX, buyer/public/admin review screens должны учесть seller reply и complaint-driven moderation

Endpoint’ов

Задач

Acceptance

Что сделать

Построить seller review list/dashboard на GET /seller/reviews
Добавить seller reply editor с state-driven блокировкой по canReply / canEditReply
Обработать REVIEW_NOT_PUBLISHED, REPLY_EDIT_WINDOW_EXPIRED, COMPLAINT_ALREADY_EXISTS как ожидаемые продуктовые состояния, а не generic error
Добавить seller complaint UX и после успешной жалобы переводить review-card в состояние PENDING_MODERATION
Показывать seller reply в buyer cabinet и public review blocks там, где он приходит из backend
В admin review detail показывать active complaint context, если отзыв попал на повторную модерацию

Подтверждение от frontend

Migration note

Это расширение review-контракта и seller dashboard surface, а не изолированный новый экран
Frontend больше не должен считать seller review interaction "локальной заметкой": reply и complaint влияют на public/admin review state machine
Требуется действие frontend: да

FE-BE-2026-03-31-01

Backend review status model и admin review moderation baseline

Готово для frontendНет ответа

buyer reviews cabinet, public item reviews и admin review moderation

Endpoint’ов

Задач

Acceptance

Что сделать

Добавить buyer-facing UI для review status badge вместо скрытого допущения "отзыв всегда сразу опубликован"
Показывать moderationNote, если отзыв отклонён или имеет seller-visible moderation пояснение
В public item reviews и rating widgets больше не ожидать, что новые только что отправленные отзывы появятся мгновенно
Построить admin review moderation queue/detail на новых /admin/moderation/reviews* endpoints
Обработать INVALID_STATUS_TRANSITION для race-safe admin moderation UI

Подтверждение от frontend

Migration note

Это контрактное изменение поведения, а не только добавление admin endpoints
Старое frontend-допущение "отзыв после submit сразу виден в public UI" теперь неверно
Требуется действие frontend: да

FE-BE-2026-03-30-05

Admin seller operational surface доведён до рабочего контура

Готово для frontendНет ответа

admin seller directory, status management и seller-facing реакция на account status

Endpoint’ов

Задач

Acceptance

Что сделать

Построить admin seller directory/list screen на GET /admin/sellers
Подключить фильтры search, status, sellerType, page, limit
Показывать seller summary и item counters прямо из backend response, а не собирать их вручную из разрозненных API
Использовать PATCH /admin/sellers/:sellerId/status из этого списка как основной status-management action
В seller-facing UI перестать трактовать response после status change как token expiry: ACCOUNT_UNDER_REVIEW и ACCOUNT_BLOCKED должны обрабатываться как account state

Подтверждение от frontend

Migration note

Нового breaking route change нет
Это operational contract package: статус account management теперь считается полноценным рабочим срезом, а не isolated action endpoint
Требуется действие frontend: да

FE-BE-2026-03-30-04

Seller item moderation state machine доведён до рабочего вида

Готово для frontendНет ответа

seller item dashboard и admin moderation должны перейти на явный moderation lifecycle вместо старых неявных переходов

Endpoint’ов

Задач

Acceptance

Что сделать

Добавить явный seller badge/UX для статуса DRAFT
Перестать считать, что create/update автоматически отправляют айтем на модерацию
Добавить UX для withdraw перед редактированием pending-айтема
Показывать latestModerationRecord.reason/comment в seller item dashboard и detail screen
Обработать новые item error codes: ITEM_PENDING, ITEM_ALREADY_PENDING, ITEM_ALREADY_ACTIVE, ITEM_MISSING_REQUIRED_FIELDS, ITEM_NOT_PENDING
Обновить admin moderation UI под новый race-safe сценарий, где non-pending item больше нельзя approve/reject

Подтверждение от frontend

Migration note

Это контрактное изменение поведения, а не только новый endpoint
Старое frontend-допущение “create/update автоматически отправляют item на модерацию” теперь неверно
Требуется действие frontend: да

FE-BE-2026-03-30-03

Upload URL стал storage-agnostic

Готово для frontendНет ответа

подготовить frontend к object storage без ломки API-контракта upload endpoint

Endpoint’ов

Задач

Acceptance

Что сделать

Использовать url из backend response как готовый src/asset URL без преобразований
Не завязывать upload UI на префикс /uploads/images/
Проверить, что seller logo/photo и item image flows не ломаются от абсолютного CDN/S3 URL

Подтверждение от frontend

Migration note

Формально breaking route change нет
Семантически это важное contract clarification: url больше не должен считаться обязательно локальным path

FE-BE-2026-03-30-02

OpenAPI response schemas для seller items и admin

Готово для frontendНет ответа

убрать manual response layer на seller item dashboard и admin slices; активный backend-blocker backlog по OpenAPI coverage теперь равен `0`

Endpoint’ов

Задач

Acceptance

Что сделать

Перегенерировать openapi/openapi.json и contract layer
Убрать ручные response-типы на seller item dashboard и admin slices
Перевести item/admin queries и mutations на generated response types без локальных transport-заглушек
Считать оставшиеся ручные response-интерфейсы в этих зонах техническим долгом, а не допустимым baseline

Подтверждение от frontend

Migration note

Breaking route change нет
Это финальный contract-completeness package по CP-104: новые backend schema fixes для этих endpoint'ов больше не требуются
204 No Content delete-маршруты остаются техническим хвостом OpenAPI-оформления, но не считаются blocker'ом для frontend

FE-BE-2026-03-30-01

OpenAPI response schemas для auth auxiliary, staff и reference

Готово для frontendНет ответа

убрать manual transport layer на auth auxiliary, staff и reference slices

Endpoint’ов

Задач

Acceptance

Что сделать

Перегенерировать openapi/openapi.json и contract layer
Убрать ручные response-типы на password reset auxiliary flow, seller staff и reference slices
Использовать generated response layer для buyer-role bind flow
Не держать custom parsers там, где shape теперь уже стабилизирован в OpenAPI

Подтверждение от frontend

Migration note

Breaking route change нет
Это не новый endpoint package, а contract-completeness package: старые ручные response-типы теперь считаются техническим долгом и должны вытесняться generated contract layer

FE-BE-2026-03-28-01

OpenAPI и контрактный контур

Готово для frontendНет ответа

source-of-truth контракт и базовый workflow синхронизации frontend с backend

Endpoint’ов

Задач

Acceptance

Что сделать

Считать OpenAPI единственным источником истины по transport-типам
Не поддерживать вручную параллельные request/response types, если endpoint уже описан в OpenAPI
Для каждого backend-пакета сначала обновлять openapi/openapi.json, затем прогонять codegen

Подтверждение от frontend

FE-BE-2026-03-28-02

Auth registration и password reset

Готово для frontendНет ответа

новый registration API и восстановление пароля

Endpoint’ов

Задач

Acceptance

Что сделать

Собрать новый registration wizard поверх check-availability, register/buyer, register/seller
Нормально маппить PHONE_TAKEN и EMAIL_TAKEN в field-level ошибки
Не строить отдельный frontend-only reset flow в обход backend-контракта
Использовать новый add-buyer-role для multi-role сценария seller → buyer

Подтверждение от frontend

Migration note

Старый POST /api/v1/auth/register сохранён только как legacy route и не должен быть опорой новой frontend-разработки

FE-BE-2026-03-28-03

Buyer profile, children, interests

Готово для frontendНет ответа

buyer cabinet и post-registration buyer flow

Endpoint’ов

Задач

Acceptance

Что сделать

Собрать UI-сценарий отсутствующего buyer profile
Развести parent и student ветки кабинета
Перевести buyer profile flow на POST/PATCH /me/profile
Подключить children CRUD и interests update к новому контракту

Подтверждение от frontend

Migration note

PUT /me/profile не должен использоваться как канонический путь для новой реализации

FE-BE-2026-03-28-04

Seller profile, addresses, Telegram, uploads

Готово для frontendНет ответа

seller onboarding/profile management и asset-related flows

Endpoint’ов

Задач

Acceptance

Что сделать

Довести seller onboarding/profile UI до актуального backend-контракта
Нормально обрабатывать field-level duplicate errors для contact phone/email
Подключить address CRUD и primary switch к новому seller area
Подключить Telegram verification/unbind без самодельного контракта
Использовать backend upload endpoint для logo/photo/image flows

Подтверждение от frontend

Migration note

PUT /seller/profile — только legacy alias, новые UI-сценарии должны строиться на PATCH

FE-BE-2026-03-28-05

Admin / governance hooks

Готово для frontendНет ответа

backend hooks, которые понадобятся admin-поверхности и governance-сценариям

Endpoint’ов

Задач

Acceptance

Что сделать

Использовать этот endpoint только в admin scope
Явно закладывать UI для INVALID_STATUS_TRANSITION
Не предполагать, что заблокированный seller сможет жить на старой refresh-сессии

Подтверждение от frontend

Frontend remediation

Где сейчас красно в `qadam-web`

Это не backend handoff, а отдельный remediation backlog по самому frontend. Он отвечает на вопрос, почему root quality gate ещё красный и какие пакеты нужно закрыть, чтобы довести `CP-103` до завершения.

FE-WEB-2026-03-30-01

Registration и profile contract drift

P0ЗапланированоBackend contract

перевести registration, buyer profile и seller profile на текущий buyer/seller/account contract из `qadam-core`

Проблем

Действий

Acceptance

Что сломано сейчас

src/features/auth/ui/RegisterForm.tsx всё ещё собирает legacy payload вида { type, profile }
src/views/me/profile/ui/MeProfilePage.tsx всё ещё пишет name, хотя backend уже ушёл на account-centric firstName/lastName
src/views/seller-dashboard/profile/ui/SellerProfilePage.tsx всё ещё читает и пишет legacy name/description seller-модель

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

перевести registration flow на check-availability, register/buyer и register/seller
убрать legacy profile envelope из frontend transport layer
buyer profile screen перевести на канонический write-contract account profile
seller profile screen перевести на текущий response/write-contract из OpenAPI вместо старой name/description модели

Связанные backend-пакеты

`FE-BE-2026-03-28-02``FE-BE-2026-03-28-03``FE-BE-2026-03-28-04`

FE-WEB-2026-03-30-02

Manual response aliases и response-shape drift

P0ЗапланированоBackend contract

убрать устаревшие ручные response aliases и привести seller/admin/leads slices к фактическому OpenAPI response shape

Проблем

Действий

Acceptance

Что сломано сейчас

src/shared/api/api-types.ts всё ещё ждёт .items там, где backend уже публикует массив напрямую
ручные aliases скрывают реальный response shape seller/admin/leads срезов
product web частично сидит на устаревшей ручной response-обвязке, хотя backend response coverage уже закрыт

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

перегенерировать openapi/openapi.json и локальный frontend contract layer
вычистить устаревшие .items assumptions из src/shared/api/api-types.ts
снять ручные response wrappers там, где current OpenAPI уже описывает массивы и объекты точно
довести seller/admin/leads/current-user aliases до текущего backend response shape

Связанные backend-пакеты

`FE-BE-2026-03-30-01``FE-BE-2026-03-30-02``FE-BE-2026-03-30-03`

FE-WEB-2026-03-30-03

Tooling и type hygiene drift

P1ЗапланированоTooling / quality

снять внутренний type/tooling drift, который не относится напрямую к backend runtime, но держит root quality gate в красном состоянии

Проблем

Действий

Acceptance

Что сломано сейчас

commitlint.config.ts падает из-за type import на @commitlint/types
src/shared/store/__tests__/catalog-filter.types.test.ts использует устаревшие enum literals, которые больше не совпадают с текущими типами
root typecheck смешивает реальные contract issues и локальный frontend hygiene debt

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

либо добавить недостающую типовую зависимость для commitlint, либо упростить конфиг без неё
привести catalog filter tests к текущим enum values и типам
убрать локальные type-only поломки, не связанные с backend handoff

FE-WEB-2026-03-30-04

Неблокирующие lint warnings и cleanup

P2ЗапланированоFrontend internal

убрать накопившиеся warnings и локальный cleanup после закрытия contract drift

Проблем

Действий

Acceptance

Что сломано сейчас

в src/entities/item/ui/ItemCard.tsx остаются any
в src/features/seller-item-form/ui/ItemForm.tsx есть warning по useEffect dependencies
в src/proxy.ts висит неиспользуемый PUBLIC_PATHS

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

снять warning'и без расширения обходных suppressions
не смешивать этот cleanup с P0/P1 remediation-пакетами

Актуальные фазы

Фазы продолжения разработки

Этап

2. Фаза A — Stabilization & Transferability

Русскоязычная каноническая документация в порядке.
Зафиксированы канонические инженерные принципы проекта и Definition of Done.
Реальный статус платформы зафиксирован в docs/project/current-state.md.
Есть единый runbook по эксплуатации.
Есть отдельные runbook по backup/restore, incident response и post-deploy checklist.
Исправлены отставшие unit-тесты и сломанные quality gates.
Есть детальный план и уже созданные bootstrap-репозитории qadam-core и qadam-web.
Есть отдельный frontend handoff-документ с git, OpenAPI и контрактным workflow.
Зафиксирована модель работы отдельной frontend-команды в qadam-web.
Есть детальный план перехода на управляемый docker-контур.
Зафиксирована текущая host-based модель деплоя и целевая migration-модель.
Production runtime переведён на qadam-core и qadam-web.
Есть ownership model, change-package standard, execution checkpoints и project-level changelog.
Есть машиночитаемый docs quality gate.
Синхронизировать docs/, specs/ и фактический код.
Зафиксировать правила передачи проекта другой команде, обязательность тестового покрытия и русскоязычной документации.
Зафиксировать ownership, change-package process, checkpoints и changelog как обязательный delivery-контур.
Убрать ложные статусы вроде not-started в платформенных спеках.
Починить backend unit-тесты, которые отстали от refresh-token логики и buyer profile поведения.
Убрать документальный и инфраструктурный drift вокруг frontend repo split и docker migration.
Зафиксировать split-репозитории как единственный operational-контур новой разработки и текущего production.
Довести roadmap-портал до состояния, в котором каноническая markdown-документация нормально перелинкована и читается как единая система.

Этап

3. Фаза B — MVP Completion

Seller может пройти путь: профиль -> айтем -> модерация -> лиды.
Buyer может пройти путь: просмотр -> карточка -> лид -> кабинет.
Admin может модерировать айтемы и работать с базовыми операционными сценариями.
Публичные страницы пригодны для SSR и базового SEO.

Этап

4. Фаза C — PMF Validation

Управляемое наполнение каталога.
Работающая воронка лидов.
Базовая операционная аналитика по лидам, продавцам и активным айтемам.
Понимание unit economics для CPL-модели.
Масштабирование acquisition.
Активный GTM по seller side.
Введение платных seller-инструментов.

Этап

5. Фаза D — CRM v1.0

Календарь и расписание.
Клиентская база.
Онлайн-запись.
Ролевая модель CRM.
SaaS billing.

Этап

6. Фаза E — Transactional Platform

Интеграция оплат.
Комиссионная модель.
Единый buyer wallet/journey.
Финансовый слой и отчётность.
Документация приведена к каноническому виду.
Backend test contour и type gate снова зелёные после auth/registration/openapi drift.
Runbook по текущему серверу зафиксирован.
Инженерные принципы передачи проекта, тестирования и документации зафиксированы.
В backend поднят базовый Swagger/OpenAPI-контур как первый исполнимый шаг к frontend repo split.
В apps/web подключён первый generated OpenAPI contract layer, и сняты runtime-зависимости от @repo/shared/@repo/prisma.
В репозитории зафиксирован versioned OpenAPI artifact и CI-проверка contract drift.
Для auth + leads backend уже публикует точные response-схемы, а frontend использует generated response types.
Seller leads экран переведён на общий query/mutation слой без прямых fetch-обходов.
Для catalog + reviews + public seller profile + buyer reviews cabinet backend уже публикует точные response-схемы, а frontend использует generated response types.
Публичный reviews flow и форма отправки отзыва переведены на общий query/mutation слой без прямых fetch-вызовов.
Устранён контрактный drift вокруг GET /me/reviews: backend, OpenAPI и frontend снова синхронизированы.
Buyer profile и seller profile уже исключены из активного OpenAPI gap backlog: их response schemas опубликованы и больше не считаются blocker'ом для generated profile contract.
Auth auxiliary, Staff и Reference data теперь тоже публикуют точные response schemas и выведены из активного OpenAPI gap backlog.
Seller Items, Admin Dashboard и Admin Moderation теперь тоже публикуют точные response schemas; активный frontend-значимый OpenAPI gap backlog закрыт полностью.
Закрыт критичный security bypass roadmap-портала: основной домен больше не открывает /roadmap, а mutation routes режут cross-origin POST.
Refresh token rotation усилена до атомарного single-use consume в Redis.
Rate limiting behind nginx теперь опирается на доверенный loopback proxy, а не на адрес reverse proxy.
API больше не слушает внешний интерфейс сервера и закрыт за локальным nginx-proxy.
Публичная доступность айтема унифицирована для каталога, public seller profile, лидов и отзывов.
SELLER_STAFF больше не редиректится в неподдержанный seller area.
Созданы и запушены отдельные bootstrap-репозитории qadam-core и qadam-web.
qadam-core и qadam-web автономно проходят install/build-контур.
qadam-web собирается из собственного openapi/openapi.json, а не требует backend checkout для codegen.
Подготовлен отдельный frontend handoff-документ с git, OpenAPI и правилами интеграции.
Frontend handoff продублирован внутри qadam-web, чтобы новая frontend-команда не зависела от legacy workspace /data/uzbek.
Production runtime переключён с /data/uzbek на qadam-core и qadam-web.
qadam-roadmap.2fab.app теперь читает документы из qadam-core/docs, а не из legacy checkout.
Roadmap-портал вынесен из apps/web в отдельный standalone-сервис apps/roadmap; основной продуктовый frontend больше не содержит встроенный roadmap runtime.
Roadmap-портал теперь корректно открывает относительные markdown-ссылки между docs, specs и docs/Agents.
Зафиксирована и доведена до рабочего вида модель передачи задач между backend/platform-командой и отдельной frontend-командой.
Исторические implementation plans из /plans проаудированы, а их выводы формально перенесены в канонические документы.
Закрыты базовые документальные gaps по backup/restore, incident response, environment matrix и post-deploy checklist.
Введены project-level execution checkpoints и отдельный project change log.
В qadam-core добавлен исполнимый docs quality gate pnpm check:docs.
Для qadam-core добавлены repo-side Gitea quality gate, PR review/security template и живой self-hosted runner; первый workflow run уже подтверждён со статусом success.
Product media переведены на S3-compatible object storage (DigitalOcean Spaces) без изменения frontend-контракта upload endpoint { url }.
Seller item moderation flow стабилизирован на backend: item lifecycle теперь идёт через DRAFT -> PENDING -> ACTIVE/REJECTED, seller может отозвать айтем с модерации, а seller/admin responses публикуют seller-visible moderation feedback.
Admin operational surface доведён до рабочего backend-контура: появился GET /admin/sellers с фильтрами и item counters, а seller-facing protected routes теперь возвращают явные ACCOUNT_UNDER_REVIEW / ACCOUNT_BLOCKED после admin status change.
CP-303 закрыт: в qadam-core уже работают backend metrics/readiness, внешний uptime/TLS monitoring для api, web и roadmap, а operational alerts уходят в отдельный Telegram-канал без ручного polling.
CP-302 закрыт: на сервере уже работает автоматический backup baseline с локальной верификацией, state file и off-host retention в S3-compatible storage.
CP-301 уже переведён из чистого baseline в live runtime: на сервер установлен Docker Engine, data-root вынесен на /mnt/qadam100gb/docker, registry/image delivery для qadam-core/api подтверждён, а production /api/* уже обслуживается qadam-api-container.service через nginx upstream qadam_api_backend -> 127.0.0.1:5002.
Для qadam-core/api уже есть не только image baseline и compose-based shadow smoke, но и source-controlled reversible cutover path; legacy qadam-api.service теперь остаётся rollback-контуром, а не каноническим production runtime.
Для qadam-web уже добавлен product web image baseline: registry namespace git.2fab.app/eldar/qadam-web-app подтверждён publish/pull smoke, а shadow runtime уже поднимается на 127.0.0.1:3002 от registry image без локального next build на production-сервере.
Следующий шаг в CP-301 теперь смещён с api на production cutover qadam-web, а затем на выравнивание qadam-roadmap, чтобы убрать временную mixed-runtime фазу.
Завершено на backend: новый registration API (check-availability, register/buyer, register/seller, password reset, add-buyer-role) и buyer profile flow (POST/PATCH /me/profile, children, interests).
Не держать profile flow в ожидании новых backend schema fixes: buyer/seller profile responses уже закрыты в OpenAPI и выведены из active gap backlog.
Синхронизировать qadam-web, который ведёт отдельная frontend-команда, с backend-контрактом POST /me/profile, PATCH /me/profile, POST /auth/register/buyer и POST /auth/register/seller.
Вести эту работу не по памяти, а через отдельный remediation backlog docs/frontend/frontend-adoption-backlog.md, где разложены contract drift, response-shape drift и tooling/type debt.
Добавить UI-обработку отсутствующего buyer profile вместо неявного поведения.
Закрыть этот поток регрессионными backend/web-проверками по уровню риска.
Seller item, admin moderation и admin operational surface уже стабилизированы на backend; минимальный stage-oriented smoke baseline для web уже добавлен и подтверждён живым прогоном на stage (10/10 проверок зелёные), но автоматический запуск после deploy и browser-level e2e остаются отдельным follow-up внутри CP-204.
Reviews backend-контур теперь замкнут: новые отзывы идут через PENDING, seller complaint flow переводит спорный отзыв в PENDING_MODERATION, admin review moderation уже вынесена в отдельные /admin/moderation/reviews routes, а публичные aggregates считают только PUBLISHED.
Не считать CP-205 закрытым раньше времени: backend-ядро review flow уже готово, но frontend adoption buyer/public/admin/seller review screens и web smoke/e2e остаются отдельным follow-up.
CP-206 уже начат на backend: public seller profile очищен до явного публичного контракта и начал отдавать backend-generated seo block для SSR/metadata; stage smoke уже включает public seller profile, поэтому незакрытый хвост теперь не в baseline, а во frontend adoption SEO metadata.
Не распыляться на новые backend contract fixes для admin, пока не закрыт базовый web regression baseline на buyer/seller/admin маршрутах.
Seller notifications больше не ограничены settings-only baseline: backend уже публикует seller-facing connect link для Telegram onboarding, принимает internal webhook бота и выпускает одноразовые verification codes через безопасный deep-link flow.
SMTP-capable email fallback/provider для seller lead notifications уже подготовлен на backend, и owner-facing status-change delivery тоже больше не является пустым флагом: при обновлении статуса активным SELLER_STAFF backend шлёт owner-уведомление по статусам из SELLER_STATUS_CHANGE_NOTIFY_STATUSES. Следующий notifications follow-up должен касаться уже не базового delivery, а transport hardening, retries и возможного расширения на новые actor/source-of-change сценарии.
После seller/admin stabilization взять Reviews и Public seller profile / SEO как отдельные MVP-пакеты с собственными execution checkpoints.
Использовать уже закрытый backend contract-layer и нулевой active backlog из openapi-gaps.md, чтобы frontend-команда сняла ручные response-типы на Seller Items, Admin Dashboard и Admin Moderation.
Довести Swagger/OpenAPI, artifact export и web codegen до устойчивого contract-layer для admin API и остаточного legacy API-layer уже на стороне потребления, а не за счёт новых backend schema fixes.
Расширить generated response contract с core product-срезов на admin API и остаточный legacy API-layer.
Закрыть остаточный cleanup из исторических web-планов: убрать дублирующиеся frontend-слои и legacy-код из qadam-web, включая components/lib и прямые fetch-обходы общего DAL.
Убрать остаточное legacy-использование /data/uzbek из активного engineering workflow.
Backup automation и off-host retention уже закрыты как отдельный delivery package; следующий инфраструктурный фокус — не backup baseline, а image-based delivery.
Для qadam-core/api уже подтверждён не только базовый container runtime, но и живой production cutover; следующий шаг — не переделывать api, а довести до такого же уровня qadam-web.
Для qadam-web уже подтверждён registry-backed shadow runtime; следующий шаг — довести это до production cutover и rollback-процедуры без простоя.
После этого подготовить container baseline для qadam-roadmap и затем унифицировать mixed runtime в единый app-level container contour.
Усилить object storage контур: при необходимости добавить CDN-fronting, lifecycle policy и off-host retention поверх уже включённого S3-compatible storage для product media.
Не смешивать этот пакет с roadmap storage: qadam-roadmap может временно оставаться на локальном диске, пока для него отдельно не появятся требования по off-host storage.
Зафиксировать следующий исполнимый пакет app-level docker migration: web + migrate, уже учитывая что api на production cutover переведён.
Подготовить отказ от временной mixed-runtime модели после подтверждения container delivery для qadam-web.
Нельзя начинать CRM, платежи и мобильные приложения до стабилизации текущего ядра.
Нельзя расширять roadmap новыми крупными направлениями, пока buyer/seller/admin-потоки не доведены до рабочего качества.
Нельзя считать старые Docker-скрипты production-истиной без отдельной ревизии.
Нельзя использовать /data/uzbek как рабочую площадку новой разработки после cutover на split-репозитории.
Стратегический roadmap: этот файл.
Операционный статус этапов: docs/project/execution-checkpoints.md.
Хронология завершённых change packages: docs/project/project-change-log.md.
Детализированный feature-backlog: docs/Agents/product-roadmap.md.
Платформенный статус: specs/qadam-platform/implementation.md.
Реальное состояние сервера: docs/project/current-state.md.

Библиотека

Документы проекта и загрузки

Архивные документы скрыты по умолчанию. Сейчас доступно 10 архивных файлов.

Show archived

Загрузка

Добавить новый markdown-документ

Загруженные файлы хранятся отдельно от репозитория. Их можно открыть, комментировать и удалить прямо из портала.

Дерево документов

Папки, категории и файлы

104 документов

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

docs

104

Agents

docs/Agents

rules

docs/Agents/rules

проект0 комм.

data-read-write-replicas.md

docs/Agents/rules/data-read-write-replicas.md

1 апр. 2026 г., 12:41 · 3 KB