Qadam Roadmap
← Назад к библиотеке
проектdocs/project/project-change-log.md

Project change log

Обновлён 14 апр. 2026 г., 17:16 · 0 комментариев

ИсходникСкачать

Project change log

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

  • Статус документа: living document
  • Актуально на: 2 апреля 2026 года
  • Владелец: backend/platform-команда
  • Пересмотр: при каждом завершённом change package, который влияет на проектный контур
  • Область применения: хронология change packages уровня платформы, инфраструктуры, документации и delivery
  • Связанные документы:

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

Этот документ ведётся отдельно от 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-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-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 шагом
  • Документы:

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

  • Дата: 2 апреля 2026 года
  • Статус: applied
  • Затронутые checkpoints:
    • без изменения checkpoint status
  • Что изменилось:
    • в канонической архитектурной документации зафиксировано правило split идентификаторов между продуктовым и аналитическим контурами
    • backend/product слой остаётся на внешних продуктовых идентификаторах в текущем UUID/string-формате
    • аналитический слой должен автоматически вводить внутренние surrogate key bigint и строить внутренние join только по ним через mapping 1:1
  • Документы:

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-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
  • Документы:

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
  • Документы:

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
  • Документы:

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
  • Документы:

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
  • Документы:

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
  • Документы:

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
  • Документы:

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 модели
  • Документы:

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
  • Документы:

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
  • Документы:

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 ещё не доведены
  • Документы:

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
  • Документы:

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
  • Документы:

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
  • Документы:

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
  • Документы:

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 контуром
  • Документы:

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
  • Документы:

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
  • Документы:

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 там, где это необходимо
  • Документы:

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 пакетом
  • Документы:

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
  • Документы:

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
  • Документы:

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
  • Документы:

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-команды
  • Документы:

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
  • Документы:

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
  • Документы:

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 и успешное удаление тестового объекта
  • Документы:

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
  • Документы:

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
  • Документы:

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
  • Документы:

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
  • Документы:

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 проходит без ошибок
  • Документы:

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
  • Документы:

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
  • Документы:

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
  • Документы:
  • Follow-up:
    • использовать execution-checkpoints.md как operational board
    • вести этот changelog для всех следующих пакетов

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

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
  • Документы:

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

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
  • Документы: