# Project change log

## Паспорт документа

- Статус документа: living document
- Актуально на: 2 апреля 2026 года
- Владелец: backend/platform-команда
- Пересмотр: при каждом завершённом change package, который влияет на проектный контур
- Область применения: хронология change packages уровня платформы, инфраструктуры, документации и delivery
- Связанные документы:
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Roadmap](./roadmap.md)
  - [Change package standard](../governance/change-package-standard.md)

## Цель документа

Этот документ ведётся отдельно от frontend changelog. Его задача — коротко фиксировать, какие пакеты изменений уже реально прошли через проект, что они изменили и какие checkpoints затронули.

## Правила ведения

- Одна запись = один завершённый change package
- Запись добавляется только по факту исполнения
- Если пакет меняет frontend-контракт, ссылка на `frontend-change-log.md` обязательна
- Если пакет меняет статус этапа, ссылка на `execution-checkpoints.md` обязательна

## Записи

## API-2026-04-06-01 — Исправлена потеря web-сессии после 15 минут при полной перезагрузке страницы

- Дата: 6 апреля 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - без изменения checkpoint status
- Что изменилось:
  - refresh cookie `qadam_rt` больше не ограничена `path=/api/v1/auth` и теперь выставляется на `path=/`, чтобы server-side proxy на обычных web-маршрутах мог читать её после истечения `qadam_at`
  - backend при выдаче новой пары токенов дополнительно чистит legacy refresh-cookie с `path=/api/v1/auth`, чтобы не оставлять дубли с одинаковым именем и разными path
  - clear/logout теперь очищает обе версии `qadam_rt`: legacy path и новый root path
  - это закрывает баг, при котором пользователь терял web-сессию примерно через 15 минут при обновлении страницы, несмотря на ещё живой refresh token
- Документы:
  - [Карта API-маршрутов](../architecture/api-routes.md)
  - [Change Log для frontend-команды](../frontend/frontend-change-log.md)

## API-2026-04-02-06 — Owner-facing status-change notifications доведены до live seller staff flow

- Дата: 2 апреля 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - без изменения checkpoint status
- Что изменилось:
  - seller lead routes `GET /seller/leads` и `PUT /seller/leads/:id/status` теперь осмысленно работают не только для owner, но и для активного `SELLER_STAFF`
  - owner-facing status-change delivery больше не остаётся пустым toggle: если статус меняет `SELLER_STAFF`, backend шлёт owner-уведомление по выбранным статусам через `Telegram -> Email fallback`
  - список отслеживаемых статусов вынесен в runtime env `SELLER_STATUS_CHANGE_NOTIFY_STATUSES`, чтобы product/platform-команда могла включать и исключать статусы без нового backend schema package
  - owner не получает бессмысленное уведомление о своём собственном статус-апдейте
- Документы:
  - [Карта API-маршрутов](../architecture/api-routes.md)
  - [Change Log для frontend-команды](../frontend/frontend-change-log.md)
  - [Текущее состояние](./current-state.md)

## API-2026-04-02-05 — Для seller lead notifications включён SMTP-capable email fallback

- Дата: 2 апреля 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - без изменения checkpoint status
- Что изменилось:
  - в `qadam-core` backend теперь не ограничивается Telegram-only попыткой доставки при создании нового лида: если Telegram недоступен, отключён или не настроен, сервис умеет перейти на SMTP-capable email fallback
  - `sellerEmail` в notification settings и в delivery context теперь резолвится из seller profile email с fallback на account email, чтобы доставка не зависела только от auth-слоя
  - `notifyStatusChangeTelegram` честно оставлен forward-compatible настройкой: текущий live lead flow не даёт отдельного owner-facing status-change trigger, поэтому пакет не притворяется завершением status-change delivery
  - в runtime/env-модели добавлены `SMTP_*` переменные для seller email notifications, но их включение на конкретном stage/prod окружении остаётся отдельным operational шагом
- Документы:
  - [Карта API-маршрутов](../architecture/api-routes.md)
  - [Change Log для frontend-команды](../frontend/frontend-change-log.md)
  - [Текущее состояние](./current-state.md)

## DOCS-2026-04-02-02 — Зафиксировано правило идентификаторов для аналитического контура

- Дата: 2 апреля 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - без изменения checkpoint status
- Что изменилось:
  - в канонической архитектурной документации зафиксировано правило split идентификаторов между продуктовым и аналитическим контурами
  - backend/product слой остаётся на внешних продуктовых идентификаторах в текущем UUID/string-формате
  - аналитический слой должен автоматически вводить внутренние surrogate key `bigint` и строить внутренние join только по ним через mapping `1:1`
- Документы:
  - [Prisma и data layer](../architecture/prisma-data-layer.md)
  - [Аналитика и observability](../architecture/analytics-observability.md)

## API-2026-04-02-04 — В seller notifications замкнут Telegram bot connect flow

- Дата: 2 апреля 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - без изменения checkpoint status
- Что изменилось:
  - в `qadam-core` seller-facing Telegram onboarding перестал быть “ручным знанием бота”: backend теперь отдаёт `GET /seller/telegram/connect-link` с коротким signed deep link
  - `POST /api/v1/internal/telegram/webhook` принимает `/start` от Telegram-бота, выпускает одноразовый 6-значный verification code и инвалидирует предыдущий незавершённый код продавца
  - `POST /seller/telegram/verify` и `DELETE /seller/telegram` ужесточены до продуктовых состояний `ALREADY_VERIFIED` и `NOT_CONNECTED`, а binding `telegramChatId` дополнительно защищён уникальностью на уровне БД
  - seller notification settings больше не показывают `telegramUsername`, если seller фактически не подключён
- Документы:
  - [Карта API-маршрутов](../architecture/api-routes.md)
  - [Change Log для frontend-команды](../frontend/frontend-change-log.md)
  - [Текущее состояние](./current-state.md)

## API-2026-04-02-03 — Поднят seller notifications baseline для новых лидов

- Дата: 2 апреля 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - без изменения checkpoint status
- Что изменилось:
  - в `qadam-core` добавлен отдельный notifications-модуль с `GET/PATCH /seller/notification-settings`
  - backend теперь хранит `NotificationSettings` и `NotificationLog`, а при создании нового лида запускает неблокирующую попытку Telegram-доставки продавцу по существующей seller Telegram binding
  - исторические seller-аккаунты без настроек больше не требуют ручной миграции в коде: settings поднимаются через `upsert`, а новые seller-регистрации создают их сразу
  - email toggle уже зафиксирован в контракте как forward-compatible setting, но SMTP/provider delivery пока сознательно не заявлен как завершённый production channel
- Документы:
  - [Карта API-маршрутов](../architecture/api-routes.md)
  - [Change Log для frontend-команды](../frontend/frontend-change-log.md)
  - [Текущее состояние](./current-state.md)

## WEB-2026-04-02-02 — Stage smoke baseline подтверждён живым прогоном

- Дата: 2 апреля 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-204`
  - `CP-206`
- Что изменилось:
  - stage-oriented smoke baseline из `qadam-web` больше не существует только на бумаге: на stage успешно прошли `10` из `10` проверок по runtime health, public pages, public item, public seller profile и buyer/seller/admin dashboard flows
  - `CP-204` остаётся `in progress`, потому что smoke ещё не встроен в автоматический post-deploy запуск и не дорос до browser-level e2e
  - у `CP-206` снят устаревший хвост про отсутствие public seller profile в stage smoke baseline; незакрытым остаётся именно frontend adoption SEO metadata
- Документы:
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Roadmap](./roadmap.md)
  - [Текущее состояние](./current-state.md)

## API-2026-04-02-02 — В auth-контур добавлена смена пароля из кабинета

- Дата: 2 апреля 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - без изменения checkpoint status
- Что изменилось:
  - в `qadam-core` добавлен новый endpoint `POST /api/v1/auth/change-password` для авторизованной смены пароля без recovery flow
  - endpoint валидирует `currentPassword`, применяет те же правила к `newPassword`, что и registration/reset-password, и публикует response schema `{ message }` в OpenAPI
  - после успешной смены пароля backend отзывает refresh token family пользователя, чтобы старые долгоживущие сессии не оставались валидными
  - из большого внешнего списка `OpenAPI gaps` дополнительные response schemas и address constraints отдельно не правились, потому что они уже были закрыты в текущем `main`; реальным незакрытым хвостом оставался только `change-password`
- Документы:
  - [Карта API-маршрутов](../architecture/api-routes.md)
  - [Change Log для frontend-команды](../frontend/frontend-change-log.md)
  - [Execution checkpoints](./execution-checkpoints.md)

## WEB-2026-04-02-01 — Для product web добавлен stage-oriented smoke baseline

- Дата: 2 апреля 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-204`
- Что изменилось:
  - в `qadam-web` добавлен исполняемый smoke script `pnpm smoke:web:flows`, который проверяет runtime health, публичные страницы `/`, `/login`, `/register`, `/forgot-password` и role-based web flows buyer/seller/admin
  - smoke использует stage env вместо жёстко прошитых данных: логины/пароли и public identifiers для item/seller передаются через `deploy/env/web-smoke.env.example`
  - `CP-204` переведён из `planned` в `in progress`: базовый smoke layer уже появился, но его ещё нужно встроить в внешний stage release-контур и позже усилить до полноценного browser-level e2e
- Документы:
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Roadmap](./roadmap.md)
  - [Текущее состояние](./current-state.md)

## DOCS-2026-04-01-02 — Зафиксирована модель stage delivery через merge в main

- Дата: 1 апреля 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - без изменения checkpoint status
- Что изменилось:
  - в канонической документации зафиксировано, что текущая машина используется для разработки, фиксов и локальных инженерных проверок, но не считается обязательным ручным stage deploy-контуром
  - добавлен отдельный документ `docs/operations/stage-delivery-model.md`, который описывает release handoff между backend и frontend и правило: согласованный merge в `main` является релизным событием для внешнего stage-сервера
  - `frontend-handoff.md`, `change-package-standard.md`, `deployment-runbook.md` и `current-state.md` синхронизированы с этой моделью и больше не оставляют двусмысленность между локальным operational runbook и внешним stage auto deploy
- Документы:
  - [Модель stage delivery и release handoff](../operations/stage-delivery-model.md)
  - [Памятка для frontend-команды](../frontend/frontend-handoff.md)
  - [Стандарт change package](../governance/change-package-standard.md)
  - [Runbook эксплуатации и деплоя](../operations/deployment-runbook.md)
  - [Текущее состояние](./current-state.md)

## OPS-2026-04-01-01 — Зафиксирован отдельный bootstrap-runbook для проверочного сервера

- Дата: 1 апреля 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - без изменения checkpoint status
- Что изменилось:
  - в канонической документации добавлен отдельный runbook `docs/operations/verification-server-bootstrap.md` для быстрого подъёма отдельного сервера, на котором одновременно работают backend и product web
  - в runbook явно зафиксировано, что уже берётся из Git, а что остаётся вне Git как runtime-конфигурация: env, secrets, nginx, TLS, БД и Redis
  - документ фиксирует рекомендуемую topology для UI-проверок: один stage-домен, `api` на `127.0.0.1:5002`, `web` на `127.0.0.1:3002`, единый `nginx` перед ними и синхронизацию `openapi.json` между `qadam-core` и `qadam-web`
- Документы:
  - [Runbook поднятия отдельного проверочного сервера](../operations/verification-server-bootstrap.md)
  - [Runbook эксплуатации и деплоя](../operations/deployment-runbook.md)
  - [Environment matrix](../operations/environment-matrix.md)
  - [README документации](../README.md)

## OPS-2026-03-31-14 — Для product web подтверждён registry-backed shadow runtime

- Дата: 31 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-301`
- Что изменилось:
  - в `qadam-web` добавлены лёгкий runtime `Dockerfile`, `.dockerignore`, compose manifest `deploy/compose/docker-compose.web-runtime.yml` и scripts `build-web-image.sh`, `publish-web-image.sh`, `smoke-web-runtime-compose.sh`
  - web image больше не требует тяжёлый multistage `pnpm install + next build` внутри Docker на production-хосте: image собирается из уже готового `.next/standalone`, `.next/static` и `public`
  - подтверждён registry namespace `git.2fab.app/eldar/qadam-web-app`: product web image опубликован, затем независимо вытянут через `docker pull` и поднят как shadow runtime на `127.0.0.1:3002`
  - `qadam-web` остаётся на host-level `systemd` в production, поэтому `CP-301` не закрыт; следующий шаг — production cutover product web и только после этого выравнивание `qadam-roadmap`
- Документы:
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Roadmap](./roadmap.md)
  - [Текущее состояние](./current-state.md)
  - [Runbook эксплуатации и деплоя](../operations/deployment-runbook.md)
  - [План перехода проекта на docker-контур](../operations/docker-contour-migration-plan.md)

## OPS-2026-03-31-13 — API переключён на container runtime через reversible cutover path

- Дата: 31 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-301`
- Что изменилось:
  - в `qadam-core` добавлены source-controlled cutover/rollback-скрипты `deploy/scripts/cutover-api-to-container.sh`, `deploy/scripts/rollback-api-to-systemd.sh` и nginx upstream switcher `deploy/scripts/set-api-upstream.sh`
  - в репозитории зафиксированы templates `deploy/nginx/qadam-api-upstream.conf` и `deploy/systemd/qadam-api-container.service`, а на сервере установлены `/etc/nginx/conf.d/qadam-api-upstream.conf`, `/etc/systemd/system/qadam-api-container.service` и `/etc/qadam/qadam-api-runtime.env`
  - public `/api/*` трафик `qadam.2fab.app` переведён с `qadam-api.service` на `qadam-api-container.service`, который запускает registry image `git.2fab.app/eldar/qadam-core-api:git-b5207058e82ae89823357172e38311e98664ac81`
  - host nginx теперь использует named upstream `qadam_api_backend -> 127.0.0.1:5002`, а legacy `qadam-api.service` остановлен и оставлен как rollback path на `127.0.0.1:5001`
  - `CP-301` остаётся `in progress`, потому что `qadam-web` и `qadam-roadmap` ещё не переведены на такой же image-based runtime и проект временно работает в mixed-runtime модели
- Документы:
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Roadmap](./roadmap.md)
  - [Текущее состояние](./current-state.md)
  - [Runbook эксплуатации и деплоя](../operations/deployment-runbook.md)
  - [План перехода проекта на docker-контур](../operations/docker-contour-migration-plan.md)

## OPS-2026-03-31-12 — Для API подтверждён registry-based delivery через Gitea Container Registry

- Дата: 31 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-301`
- Что изменилось:
  - для `qadam-core/api` добавлен publish script `deploy/scripts/publish-api-image.sh`, который публикует versioned image tag в Gitea Container Registry `git.2fab.app/eldar/qadam-core-api`
  - compose-based shadow smoke `deploy/scripts/smoke-api-runtime-compose.sh` теперь умеет работать и от registry image, а не только от локально собранного образа
  - repo-side workflow `Quality Gate` дополнен job `Publish API Image`, который на `push` в `main` публикует `git-<commit>` image tag после зелёного `API Container Smoke`
  - registry path подтверждён по факту: опубликован тестовый image `git.2fab.app/eldar/qadam-core-api:registry-smoke-4805b86`
  - `CP-301` остаётся `in progress`: API registry delivery уже работает, но production cutover и аналогичный канонический image-baseline для `qadam-web` ещё остаются отдельным follow-up
- Документы:
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Roadmap](./roadmap.md)
  - [Текущее состояние](./current-state.md)
  - [Runbook эксплуатации и деплоя](../operations/deployment-runbook.md)
  - [План перехода проекта на docker-контур](../operations/docker-contour-migration-plan.md)

## OPS-2026-03-31-11 — API image delivery baseline доведён до build script и compose shadow smoke

- Дата: 31 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-301`
- Что изменилось:
  - для `qadam-core/api` добавлен канонический build script `deploy/scripts/build-api-image.sh`, который собирает образ с OCI labels и результативным тегом `qadam-core-api:git-<commit>`
  - для `qadam-core/api` добавлен compose-based shadow smoke `deploy/scripts/smoke-api-runtime-compose.sh`, который поднимает runtime-manifest `deploy/compose/docker-compose.api-runtime.yml` на `127.0.0.1:5002` с production env без остановки host-level `qadam-api`
  - в `deploy/env/api-runtime.env.example` зафиксирован template delivery-обвязки для image-based runtime `api`
  - `CP-301` остаётся `in progress`: API image delivery baseline уже воспроизводим на сервере, но registry/image push и production cutover ещё остаются отдельным follow-up
- Документы:
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Roadmap](./roadmap.md)
  - [Текущее состояние](./current-state.md)
  - [Runbook эксплуатации и деплоя](../operations/deployment-runbook.md)

## OPS-2026-03-31-10 — Repo-side API container smoke добавлен в quality gate

- Дата: 31 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-301`
- Что изменилось:
  - self-hosted runner `qadam-core-runner` получил доступ к Docker daemon через группу `docker`
  - в `qadam-core` добавлен self-contained сценарий `scripts/smoke-api-container.sh` и root-команда `pnpm smoke:api-container`
  - container smoke поднимает временные PostgreSQL и Redis контейнеры, прогоняет `run-migrations.sh` внутри API image и проверяет `health/ready` и `metrics`
  - repo-side workflow `Quality Gate` расширен отдельным job `API Container Smoke`, который собирает `apps/api/Dockerfile` и запускает этот smoke без зависимости от production БД
  - `CP-301` остаётся `in progress`: image baseline и repo-side smoke уже работают, но registry/image delivery и production cutover ещё не доведены
- Документы:
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Текущее состояние](./current-state.md)
  - [Runbook эксплуатации и деплоя](../operations/deployment-runbook.md)

## OPS-2026-03-31-09 — Подготовлен API container baseline и Docker storage вынесен на отдельный диск

- Дата: 31 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-301`
- Что изменилось:
  - на сервер установлен Docker Engine, а его `data-root` переведён на `/mnt/qadam100gb/docker`, чтобы image build не забивал корневой раздел
  - в `qadam-core` канонизирован `apps/api/Dockerfile`: runtime user, `dumb-init`, healthcheck и отдельные helper scripts для migrations/seed
  - добавлен первый deployment manifest `deploy/compose/docker-compose.api-runtime.yml` для `api`, `migrate` и `seed`
  - backend bootstrap больше не создаёт локальные uploads и не монтирует static `/uploads`, если `OBJECT_STORAGE_DRIVER=s3`
  - подтверждён первый container smoke: image `qadam-core-api:cp301-smoke` собирается, `run-migrations.sh` проходит, контейнер стартует на `127.0.0.1:5002`, а `GET /api/v1/health` отвечает `200`
  - `CP-301` переведён из `planned` в `in progress`; host-based runtime всё ещё остаётся каноническим production-контуром до отдельного cutover
- Документы:
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Roadmap](./roadmap.md)
  - [Текущее состояние](./current-state.md)
  - [Runbook эксплуатации и деплоя](../operations/deployment-runbook.md)
  - [План перехода проекта на docker-контур](../operations/docker-contour-migration-plan.md)

## OPS-2026-03-31-08 — Backup alerting переведён на fail/recovery-only логику

- Дата: 31 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - без изменения checkpoint status
- Что изменилось:
  - backup runtime теперь читает предыдущее состояние из `QADAM_BACKUP_STATE_FILE` и больше не шлёт повторяющиеся failure-уведомления на каждый последующий неуспешный прогон
  - Telegram alert для backup теперь отправляется только при первом переходе `ok -> failed` и при следующем `failed -> ok` как `RECOVERY`
  - обычные успешные nightly backup-run'ы остаются тихими, если явно не включён `QADAM_BACKUP_NOTIFY_ON_SUCCESS=true`
- Документы:
  - [Runbook резервного копирования и восстановления](../operations/backup-restore-runbook.md)
  - [Environment matrix](../operations/environment-matrix.md)

## OPS-2026-03-31-07 — Автоматизирован baseline backup и off-host retention

- Дата: 31 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-302`
- Что изменилось:
  - в `qadam-core` добавлен исполняемый backup runtime `scripts/backup-runtime.mjs` и root-команда `pnpm backup:run`
  - на сервере подняты `qadam-backup.service` и `qadam-backup.timer`, которые ежедневно снимают production snapshot без ручного запуска
  - backup-сценарий теперь включает `pg_dump`, API/roadmap storage, roadmap feedback overlay и runtime config, а также локальную верификацию через `pg_restore --list` и `SHA256SUMS`
  - off-host archive реально выгружается в S3-compatible storage, а state последнего прогона фиксируется в `/var/lib/qadam-backup/state.json`
  - retention policy уже работает автоматически: `7` дней локально и `30` дней off-host
- Документы:
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Runbook резервного копирования и восстановления](../operations/backup-restore-runbook.md)
  - [Environment matrix](../operations/environment-matrix.md)
  - [Текущее состояние](./current-state.md)

## OPS-2026-03-31-04 — В backend поднят monitoring baseline с readiness и Prometheus metrics

- Дата: 31 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-303`
- Что изменилось:
  - `qadam-core` теперь публикует `GET /health`, `GET /health/live`, `GET /health/ready` и `GET /metrics`
  - readiness probe реально проверяет primary PostgreSQL и Redis и отдаёт machine-readable component status с latency
  - `GET /metrics` отдаёт Prometheus-compatible runtime/process/http metrics и сознательно ограничен loopback-only доступом
  - в backend появился базовый HTTP/runtime metrics contour на `prom-client`, но внешний uptime/TLS monitoring пока остаётся отдельным follow-up
- Документы:
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Roadmap](./roadmap.md)
  - [Карта API-маршрутов](../architecture/api-routes.md)
  - [Аналитика и observability](../architecture/analytics-observability.md)

## OPS-2026-03-31-05 — Подготовлен Telegram alert channel для monitoring-контура

- Дата: 31 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-303`
- Что изменилось:
  - для production зафиксирован `TELEGRAM_ALERT_CHAT_ID` канала health-уведомлений
  - в `qadam-core` добавлен reusable sender `pnpm telegram:alert`, который шлёт сообщения через `TELEGRAM_BOT_TOKEN` и `TELEGRAM_ALERT_CHAT_ID`
  - deployment runbook и environment matrix синхронизированы с новым operational alert-delivery контуром
- Документы:
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Environment matrix](../operations/environment-matrix.md)
  - [Runbook эксплуатации и деплоя](../operations/deployment-runbook.md)

## OPS-2026-03-31-06 — Поднят внешний uptime/TLS monitoring для api, web и roadmap

- Дата: 31 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-303`
- Что изменилось:
  - в `qadam-core` добавлен stateful monitor `scripts/monitor-runtime.mjs`, который внешне проверяет product web, API readiness, roadmap web и TLS обоих доменов
  - на сервере подняты `qadam-monitor.service` и `qadam-monitor.timer` с периодом 5 минут
  - монитор сохраняет dedupe/recovery state в `/var/lib/qadam-monitor/state.json` и шлёт алерты в Telegram только на изменение статуса
  - `CP-303` переведён в `completed`, потому что backend metrics/readiness, внешний uptime/TLS monitoring и alert delivery теперь реально работают как единый operational baseline
- Документы:
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Текущее состояние](./current-state.md)
  - [Environment matrix](../operations/environment-matrix.md)
  - [Runbook эксплуатации и деплоя](../operations/deployment-runbook.md)

## CORE-2026-03-31-03 — Public seller profile переведён на явный публичный SEO-контракт

- Дата: 31 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-206`
- Что изменилось:
  - `GET /sellers/:id` больше не отдаёт прямой re-use приватного seller profile shape и публикует отдельный санитизированный public contract
  - public response теперь включает backend-generated `seo` block: `title`, `description`, `canonicalUrl`, `openGraph`, `jsonLd`
  - backend режет non-active seller profile как `404` и не включает hidden seller addresses в публичный payload
  - optional env `PUBLIC_WEB_BASE_URL` задокументирован как источник canonical URLs; при его отсутствии backend выводит базовый public URL из `NEXT_PUBLIC_API_URL`
- Документы:
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Roadmap](./roadmap.md)
  - [Карта API-маршрутов](../architecture/api-routes.md)
  - [Change Log для frontend-команды](../frontend/frontend-change-log.md)

## CORE-2026-03-31-02 — Seller review reply и complaint flow добавлены в backend review contour

- Дата: 31 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-205`
- Что изменилось:
  - backend публикует seller review surface: `GET /seller/reviews`, `PATCH /seller/reviews/:id/reply`, `POST /seller/reviews/:id/complaint`
  - seller теперь может ответить на опубликованный отзыв, а редактирование ответа ограничено 48-часовым окном
  - complaint-driven moderation замкнута end-to-end: seller complaint переводит отзыв в `PENDING_MODERATION`, отзыв временно исчезает из public aggregates, а admin moderation завершает сценарий публикацией или отклонением
  - `GET /me/reviews`, `GET /catalog/items/:slug/reviews`, seller review list и admin moderation detail теперь согласованно публикуют `sellerReply`, `sellerReplyAt` и `activeComplaint` там, где это необходимо
- Документы:
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Roadmap](./roadmap.md)
  - [Карта API-маршрутов](../architecture/api-routes.md)
  - [Change Log для frontend-команды](../frontend/frontend-change-log.md)

## CORE-2026-03-31-01 — Backend review status model и admin review moderation baseline

- Дата: 31 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-205`
- Что изменилось:
  - в Prisma и backend введена status-модель `Review`: новые отзывы создаются в `PENDING`, а исторические существующие отзывы мигрированы в `PUBLISHED`
  - `GET /me/reviews` теперь отдаёт `status` и `moderationNote`, поэтому buyer review cabinet может жить без скрытого допущения "любой отзыв сразу опубликован"
  - `GET /catalog/items/:slug/reviews` и rating/reviews aggregates в catalog/public seller profile теперь считают только `PUBLISHED`
  - опубликован admin review moderation surface: `GET /admin/moderation/reviews`, `GET /admin/moderation/reviews/:id`, `PATCH /admin/moderation/reviews/:id`
  - `ReviewStatus` уже включает `PENDING_MODERATION` как следующий шаг для complaint-driven moderation, но seller complaint/reply flow остаётся отдельным follow-up пакетом
- Документы:
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Roadmap](./roadmap.md)
  - [Карта API-маршрутов](../architecture/api-routes.md)
  - [Change Log для frontend-команды](../frontend/frontend-change-log.md)

## OPS-2026-03-30-09 — Runner cache и hostexecutor workspace вынесены с root в /tmp

- Дата: 30 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-007`
- Что изменилось:
  - `qadam-core-runner.service` теперь выставляет `XDG_CACHE_HOME=/tmp/act_runner-cache` и `TMPDIR=/tmp/act_runner-tmp`
  - `/opt/act_runner/.cache` переведён в symlink на `/tmp/act_runner-cache`
  - очищены старые root-based runner caches и root pnpm store, из-за которых `Quality Gate` падал на `ENOSPC` при `prisma generate`
  - корневой раздел перестал быть основным местом для runner workspace и Prisma engine cache
- Документы:
  - [Текущее состояние](./current-state.md)
  - [Runbook эксплуатации и деплоя](../operations/deployment-runbook.md)
  - [CI/CD и deployment rules](../Agents/rules/ci-deployment.md)

## CORE-2026-03-30-08 — Admin operational surface доведён до рабочего контура

- Дата: 30 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-203`
- Что изменилось:
  - в backend добавлен `GET /admin/sellers` с фильтрами `search`, `status`, `sellerType`, `page`, `limit`
  - admin seller summary теперь отдаёт `displayName`, contact fields, `telegramConnected` и item counters (`totalItems`, `pendingItems`, `activeItems`), чтобы status-management не держался на ручном знании `sellerId`
  - `PATCH /admin/sellers/:sellerId/status` подтверждён runtime smoke-сценарием на временном seller-аккаунте
  - `JwtAuthGuard` перестал маскировать `ACCOUNT_UNDER_REVIEW / ACCOUNT_BLOCKED` под generic `Invalid or expired token`, поэтому seller-facing protected routes теперь честно отражают account state после admin status change
- Документы:
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Roadmap](./roadmap.md)
  - [Карта API-маршрутов](../architecture/api-routes.md)
  - [Change Log для frontend-команды](../frontend/frontend-change-log.md)

## CORE-2026-03-30-07 — Seller item moderation flow переведён на явную status-модель

- Дата: 30 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-202`
- Что изменилось:
  - item lifecycle на backend переведён на явный `DRAFT -> PENDING -> ACTIVE/REJECTED`
  - добавлен endpoint `POST /seller/items/:id/withdraw`, чтобы seller мог вернуть pending-айтем обратно в draft перед редактированием
  - seller item responses и admin moderation responses теперь публикуют seller-visible moderation feedback через `latestModerationRecord` и `moderationHistory`
  - admin approve/reject больше не принимают решение по non-pending item и режут повторную модерацию как явный status conflict
- Документы:
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Roadmap](./roadmap.md)
  - [Change Log для frontend-команды](../frontend/frontend-change-log.md)

## DOCS-2026-03-30-06 — Frontend remediation backlog вынесен в отдельный канонический документ

- Дата: 30 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-103`
- Что изменилось:
  - текущая краснота `qadam-web` разложена на отдельные remediation-пакеты вместо неявного статуса `frontend ещё не синхронизирован`
  - contract drift, response-shape drift и tooling/type hygiene разделены по приоритетам `P0/P1/P2`
  - execution checkpoints и roadmap теперь ссылаются на отдельный frontend remediation backlog как на рабочий operational слой для frontend-команды
- Документы:
  - [Frontend adoption backlog](../frontend/frontend-adoption-backlog.md)
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Roadmap](./roadmap.md)

## OPS-2026-03-30-03 — На roadmap-портале добавлен frontend feedback loop

- Дата: 30 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - без изменения checkpoint status
- Что изменилось:
  - на `qadam-roadmap.2fab.app` появился отдельный блок `Что сейчас должна сделать frontend-команда`, который автоматически собирается из `docs/frontend/frontend-change-log.md`
  - для frontend-impact пакетов со статусом `ready_for_frontend` портал теперь показывает обратную связь `В работе`, `Сделано`, `Игнорировать`
  - note-only записи теперь можно явно помечать строкой `Требуется действие frontend: нет`, чтобы на портале не появлялись кнопки подтверждения
  - обратная связь frontend сохраняется отдельно от канонического markdown-слоя как operational overlay, а не переписывает backend changelog
- Документы:
  - [Change Log для frontend-команды](../frontend/frontend-change-log.md)
  - [Памятка для frontend-команды](../frontend/frontend-handoff.md)
  - [Текущее состояние](./current-state.md)

## DOCS-2026-03-30-05 — Русский язык commit message зафиксирован как обязательное правило

- Дата: 30 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - без изменения checkpoint status
- Что изменилось:
  - в `change package standard` закреплено требование писать commit message и squash merge message на русском языке
  - инженерные принципы синхронизированы с этим правилом как с обязательной частью change management
  - внутренняя rule-card по Git/CI обновлена на русскоязычные примеры commit messages
  - PR template теперь явно напоминает о русском commit message для merge
  - в `qadam-core` добавлен локальный шаблон `.gitmessage.txt` для единообразной подготовки commit message
- Документы:
  - [Change package standard](../governance/change-package-standard.md)
  - [Инженерные принципы](../governance/engineering-principles.md)
  - [Git and CI Workflow](../Agents/rules/ci-git-workflow.md)

## CORE-2026-03-30-04 — Product media переведены на S3-compatible object storage

- Дата: 30 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-304`
- Что изменилось:
  - в backend добавлен storage adapter `local | s3` для `POST /api/v1/upload/image` на базе S3-compatible driver
  - upload tests покрывают и локальный driver, и S3-compatible upload path
  - env validation и `.env.example` расширены под object storage runtime
  - upload contract формализован как `{ url: string }`, где `url` является готовым публичным URL, а не обязательно локальным `/uploads/images/...`
  - production runtime `qadam-api` переведён на `OBJECT_STORAGE_DRIVER=s3` с `DigitalOcean Spaces`
  - для Spaces-контура добавлен `S3_OBJECT_ACL=public-read`, чтобы новые объекты сразу были доступны по публичному URL
  - живой smoke upload подтвердил `200 OK` по публичному object URL и успешное удаление тестового объекта
- Документы:
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Environment matrix](../operations/environment-matrix.md)
  - [Change Log для frontend-команды](../frontend/frontend-change-log.md)

## DOCS-2026-03-30-03 — S3/object storage scope нормализован в roadmap и env-модели

- Дата: 30 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-304`
- Что изменилось:
  - в roadmap зафиксирован отдельный пакет перехода product media на S3-совместимое object storage
  - в execution checkpoints добавлен `CP-304` как отдельный delivery-пакет
  - текущее состояние проекта уточнено: product uploads должны уходить в object storage, а roadmap storage остаётся отдельным локальным контуром
  - в environment matrix и docker migration plan зафиксировано правило: S3/object storage credentials не попадают в Dockerfile и поставляются только через runtime env/secrets
- Документы:
  - [Roadmap](./roadmap.md)
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Environment matrix](../operations/environment-matrix.md)
  - [Docker contour migration plan](../operations/docker-contour-migration-plan.md)

## OPS-2026-03-30-02 — Repo-side CI quality gate и PR review/security baseline

- Дата: 30 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-007`
- Что изменилось:
  - в репозиторий добавлен Gitea workflow `.gitea/workflows/quality-gate.yml` для `check-types`, `test`, `build`, `export:openapi`, проверки committed OpenAPI artifact и `check:docs`
  - добавлен `.gitea/PULL_REQUEST_TEMPLATE.md` как обязательный PR review/security checklist
  - governance и internal CI rules синхронизированы с repo-side quality gate
  - на сервере поднят `act_runner` как `systemd`-сервис `qadam-core-runner`
  - runner `qadam-core-runner-01` зарегистрирован в `eldar/qadam-core` и первый workflow run `Quality Gate` завершился в Gitea со статусом `success`
  - workflow очищен от `setup-node` cache-save, чтобы не плодить non-fatal ошибки artifact cache на ограниченном host disk
  - `CP-007` переведён в `completed`
- Документы:
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Roadmap](./roadmap.md)
  - [Change package standard](../governance/change-package-standard.md)
  - [Инженерные принципы](../governance/engineering-principles.md)

## CORE-2026-03-30-03 — OpenAPI response schemas для seller items и admin, завершение CP-104

- Дата: 30 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-104`
- Что изменилось:
  - backend начал публиковать response `content` для `seller/items` dashboard flow, `admin/stats`, `admin/leads` и moderation endpoints
  - `openapi.json` пересобран, а активный frontend-значимый backlog response gaps сокращён до `0`
  - `CP-104` переведён в `completed`
  - frontend-команда получила финальный handoff-пакет по seller/admin contract slice
- Документы:
  - [OpenAPI gaps](../architecture/openapi-gaps.md)
  - [Roadmap](./roadmap.md)
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Change Log для frontend-команды](../frontend/frontend-change-log.md)

## CORE-2026-03-30-02 — OpenAPI response schemas для auth auxiliary, staff и reference

- Дата: 30 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-104`
- Что изменилось:
  - backend начал публиковать response `content` для `forgot-password`, `verify-reset-code`, `reset-password` и `add-buyer-role`
  - backend начал публиковать response schemas для `seller/staff`, `catalog/subjects`, `catalog/locations` и публичного `/subjects`
  - `openapi.json` пересобран, а active backlog `CP-104` сократился с `30` до `13` endpoint'ов
  - frontend-команда получила отдельный handoff-пакет на этот contract slice
- Документы:
  - [OpenAPI gaps](../architecture/openapi-gaps.md)
  - [Roadmap](./roadmap.md)
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Change Log для frontend-команды](../frontend/frontend-change-log.md)

## CORE-2026-03-30-01 — Backend quality gate stabilization

- Дата: 30 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-006`
- Что изменилось:
  - `jwt-auth.guard.spec.ts` синхронизирован с актуальной async guard-логикой и `AuthService`
  - `openapi/schemas.spec.ts` синхронизирован с текущим `current user` schema contract
  - `pnpm -C /data/qadam-core test` снова проходит полностью
  - `pnpm -C /data/qadam-core check-types` проходит без ошибок
- Документы:
  - [Roadmap](./roadmap.md)
  - [Execution checkpoints](./execution-checkpoints.md)

## DOCS-2026-03-30-02 — Roadmap и execution checkpoints приведены к одному уровню детализации

- Дата: 30 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-006`
  - `CP-205`
  - `CP-206`
- Что изменилось:
  - из roadmap убрано дублирование frontend adoption пакета между `Sprint 1` и `Sprint 3`
  - backend test и quality gate stabilization вынесен в отдельный `CP-006` вместо ложного ощущения, что тема уже полностью закрыта
  - `Reviews` и `Public seller profile / SEO` получили собственные MVP checkpoints
  - execution board теперь явно фиксирует свою границу детализации относительно стратегических фаз `C-D-E`
- Документы:
  - [Roadmap](./roadmap.md)
  - [Execution checkpoints](./execution-checkpoints.md)

## DOCS-2026-03-30-01 — OpenAPI gaps применены к roadmap и checkpoints

- Дата: 30 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-103`
  - `CP-104`
- Что изменилось:
  - `openapi-gaps` нормализован как канонический working reference по активному backlog из `30` frontend-значимых endpoint'ов
  - buyer/seller profile response schemas выведены из активного gap backlog как уже закрытые
  - roadmap теперь явно относит remaining OpenAPI work к `Auth auxiliary`, `Staff`, `Reference data`, `Seller Items`, `Admin Dashboard` и `Admin Moderation`
  - execution checkpoints уточнены: `CP-103` больше не считает profile coverage blocker'ом, а `CP-104` ведёт оставшийся response-schema backlog
- Документы:
  - [OpenAPI gaps](../architecture/openapi-gaps.md)
  - [Roadmap](./roadmap.md)
  - [Execution checkpoints](./execution-checkpoints.md)

## DOCS-2026-03-29-01 — Документационный baseline соответствия

- Дата: 29 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-004`
  - `CP-005`
- Что изменилось:
  - добавлены runbook-документы `backup/restore`, `incident response`, `environment matrix`, `post-deploy checklist`
  - добавлены `ownership model`, `change package standard`, `glossary`, `api conventions`
  - введены отдельные `execution checkpoints` и `project change log`
  - добавлен исполнимый `docs quality gate`
- Документы:
  - [Execution checkpoints](./execution-checkpoints.md)
  - [Change package standard](../governance/change-package-standard.md)
  - [Backup/restore runbook](../operations/backup-restore-runbook.md)
- Follow-up:
  - использовать `execution-checkpoints.md` как operational board
  - вести этот changelog для всех следующих пакетов

## CORE-2026-03-28-01 — Registration API и профильные контракты

- Дата: 28 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-102`
- Что изменилось:
  - добавлены новые registration endpoints buyer/seller
  - добавлены password reset flows
  - buyer/seller profile contracts приведены к каноническому виду
  - добавлены `subjects`, upload endpoint и admin seller status management
- Документы:
  - [Требования к registration API](../product/requirements-api-registration.md)
  - [Карта API-маршрутов](../architecture/api-routes.md)
  - [Change Log для frontend-команды](../frontend/frontend-change-log.md)

## OPS-2026-03-28-01 — Security hardening и runtime isolation

- Дата: 28 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-001`
  - `CP-002`
- Что изменилось:
  - roadmap-портал изолирован на отдельном runtime
  - API переведён на loopback-only bind
  - refresh token consume сделан атомарным
  - primary host больше не обслуживает `/roadmap`
- Документы:
  - [Текущее состояние](./current-state.md)
  - [Runbook эксплуатации и деплоя](../operations/deployment-runbook.md)
  - [Security review](../audits/security-review.md)

## CORE-2026-03-27-01 — OpenAPI и frontend handoff baseline

- Дата: 27 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-101`
- Что изменилось:
  - поднят Swagger/OpenAPI runtime
  - зафиксирован versioned artifact
  - введены frontend handoff и frontend change log
- Документы:
  - [Памятка для frontend-команды](../frontend/frontend-handoff.md)
  - [Change Log для frontend-команды](../frontend/frontend-change-log.md)
  - [API conventions](../architecture/api-conventions.md)

## OPS-2026-03-27-01 — Split-репозитории и production cutover

- Дата: 27 марта 2026 года
- Статус: `applied`
- Затронутые checkpoints:
  - `CP-001`
- Что изменилось:
  - созданы и опубликованы `qadam-core` и `qadam-web`
  - production переведён с legacy checkout на split-репозитории
  - `qadam-roadmap` читает документы из `qadam-core`
- Документы:
  - [Текущее состояние](./current-state.md)
  - [Runbook эксплуатации и деплоя](../operations/deployment-runbook.md)
  - [Roadmap](./roadmap.md)