# Общий чек-лист перед PR

Используется как self-check перед созданием PR. В PR достаточно написать: «чек-лист выполнен, релевантно N пунктов, все выполнены».

## Общее
- Не размыты доменные границы: один сервис/приложение = один bounded context; нет “service-олигарха”.
- Зона выбрана корректно: `internal|external|staff|jobs|dev` (см. `docs/design-guidelines/common/project_architecture.md`).
- Для `external|staff` edge остаётся thin-edge (валидация/auth/маршрутизация), без доменной логики backend.
- Перед написанием кода перечитаны профильные гайды по размещению:
  - backend: `docs/design-guidelines/go/services_design_requirements.md`;
  - frontend: `docs/design-guidelines/vue/frontend_architecture.md`, `docs/design-guidelines/vue/frontend_code_rules.md`, `docs/design-guidelines/vue/frontend_data_and_state.md`;
  - общие принципы: `docs/design-guidelines/common/design_principles.md`.
- Контракты транспорта не “вшиты в код строками” и имеют источник правды:
  - gRPC: целевой `proto/` после его повторного создания (версионирование/совместимость)
  - HTTP: OpenAPI YAML только для gateway-поверхностей
  - async/webhook payloads: AsyncAPI YAML (если используются)
- Внутренние доменные сервисы не публикуют прямые OpenAPI-контракты для бизнес-ручек; внешний HTTP доступ оформляется через gateway.
- Стабильные `v1` контракты транспорта покрывают весь согласованный объём доменного API; частичный контракт имеет явный предварительный статус.
- Если контракт создан до полной реализации, документ поставки фиксирует реализованный срез и бэклог, чтобы не считать контрактную готовность кодовой готовностью.
- Для live-кластера проверен безопасный путь эволюции контрактов: breaking change в `proto`, OpenAPI или AsyncAPI допустим только при согласованном обновлении всех потребителей без live rolling gap; иначе используется staged путь `add -> migrate consumers -> remove`.
- Модели/типы/DTO размещены по слоям, а не ad-hoc в service/handler/component файлах.
- Повторяющиеся литералы и ключи вынесены в централизованные константы/enum/type-alias.
- Повторяемые типы событий, типы агрегатов, scope/action ключи и другие доменные идентификаторы не передаются строковыми литералами в production-коде.
- Helper-код размещён по уровню переиспользования:
  - локальный файл (только одно место использования);
  - пакет/модуль (`*_helpers.*`, `lib/*`);
  - целевой `libs/*` (если используется в нескольких сервисах/приложениях и каталог уже заново создан).
- В production-коде нет анонимных структур/объектов для контрактов/персистентных payload-моделей.
- Секреты не хардкодятся и не коммитятся; в логах нет секретов/PII.
- Сырые значения секретов не сериализуются, не попадают в БД, события, тело аудита, трассировку, метки метрик или ошибки; для разрешённых ссылок используется общий secret resolver или профильный безопасный контракт.
- Имена platform env/secrets/CI variables унифицированы с префиксом `KODEX_`;
  имена без префикса `KODEX_` не добавляются.
- Kubernetes манифесты не “вшиты” heredoc’ами в bash: шаблоны лежат в целевом deploy-каталоге,
  а рендер/применение выполняются Go-рантаймом новой архитектуры.
- Shell-скрипты в контуре проверок не содержат доменные smoke/e2e сценарии. Допустимы только тонкие
  bootstrap/deploy обвязки, Make target runners и wrappers над Go tooling; интеграционные проверки
  реализуются как Go tests или отдельные Go integration runners.
- Для runtime-токенов дефолтные TTL не меньше времени жизни соответствующих контейнеров;
  для MCP baseline TTL не ниже `24h`.
- Для multi-service deploy у каждого deployable-сервиса есть собственные image vars/repositories
  (шаблон нейминга: `KODEX_<SERVICE>_IMAGE` и `KODEX_<SERVICE>_INTERNAL_IMAGE_REPOSITORY`).
- Dockerfile deployable-сервиса содержит обязательные стадии `build`, `dev`, `prod`;
  стадия `dev` поддерживает hot reload, а стадия `prod` не зависит от исходников и инструментов разработки.
- Dockerfile получает все нужные входы сборки и генерации: профильные `libs/**`, `proto/**`,
  `specs/openapi/**`, `specs/asyncapi/**` и lock-файлы пакетного менеджера, если сервис их использует.
- При изменении состава deployable-сервисов синхронно обновлены runtime deploy, build orchestration, bootstrap sync и документация новой архитектуры.
- Порядок выкладки production задан явно и соблюдён:
  stateful dependencies -> migrations -> internal domain services -> edge services -> frontend;
  ожидание зависимостей выполнено через `initContainers` в Kubernetes-манифестах.
- Если менялся набор PostgreSQL-БД, миграций или runtime DSN, синхронно обновлены:
  `services.yaml`, `deploy/base/postgres/secrets.yaml.tpl`,
  `deploy/base/postgres/bootstrap-databases.sh`, `deploy/base/postgres/postgres.yaml.tpl`,
  профильный `deploy/base/<db-owner>/migrations.yaml.tpl`, `bootstrap/host/config.env.example`,
  `bootstrap/host/bootstrap_cluster.sh` и соответствующая архитектурная документация.
- Уже применённые миграции не редактируются и не переупорядочиваются; схема меняется новой forward-only additive migration, а destructive/drop/rename оформляется отдельным путём `expand -> migrate -> contract`.
- Live drift исправляется новой миграцией или явным runbook/deploy шагом, а не ручным SQL в production.
- Источник defaults не размножен: корневой `services.yaml` владеет версиями/образами/deploy inventory,
  Go tooling читает его через `libs/go/stackinventory`, Go config владеет безопасными runtime
  defaults сервиса, Kubernetes templates не дублируют эти defaults через `envOr`, а
  `bootstrap/host/config.env.example` содержит только локальный install-профиль и
  secret/bootstrap seed-поля.
- Новые обязательные env/secrets/config имеют staged rollout path или безопасную диагностику; изменение не ломает старт уже развёрнутого сервиса без явного runbook шага.
- Изменения deploy tooling сохраняют последовательное обновление существующего live-кластера: порядок migrations, сервисов, edge и frontend задан явно и проверяем.
- Вынос общего кода в целевой `libs/*` оправдан (>= 2 потребителя); нет “god-lib”.
- Если общий код или локальный контракт стал зависимостью deployable-сервиса, `services.yaml` `spec.versions.<service>.bumpOn` синхронно обновлён для всех потребителей, чтобы изменение зависимости поднимало версии и образы сервисов.
- Новый production-код не размещён внутри устаревших или архивных каталогов.
- Если добавлена/обновлена внешняя зависимость, обновлён
  `docs/design-guidelines/common/external_dependencies_catalog.md`.
- Для русскоязычных документов, PR и комментариев проверено отсутствие лишней смеси русского и английского; английские термины оставлены только там, где они действительно нужны как точные технические идентификаторы.

## Специфика kodex
- Поддержка оркестрации ограничена Kubernetes; нет кода под другие оркестраторы.
- Kubernetes-операции выполняются через SDK/интерфейсы (не shell-first как основной путь).
- Интеграция с репозиториями идет через интерфейс провайдера; GitHub-специфика не просачивается в домен.
- Для agent runtime соблюдён split access model:
  - git transport (commit/push в рабочую ветку) допускает отдельный bot-token в pod;
  - governance-операции GitHub/Kubernetes (issue/pr/comments/labels/branch context/runtime actions) выполняются через MCP policy/audit контур.
- Процессы запускаются webhook-событиями; workflow-first сценарии не добавлены в обход архитектуры.
- Состояние long-running процессов, слотов, агентных запусков и блокировок хранится в PostgreSQL.
- Данные, требующие гибкой структуры, хранятся в `JSONB`; векторный поиск использует `pgvector`.
- Секреты платформы читаются из env; repo-токены хранятся шифрованно.
- Новые product/runtime switches, которые должны управляться на лету, не введены как env-only flags:
  они оформлены через typed platform settings catalog с явными reload semantics и audit trail.

## Профильные чек-листы
- Если PR затрагивает Go: выполнен `docs/design-guidelines/go/check_list.md`.
- Если PR затрагивает Vue: выполнен `docs/design-guidelines/vue/check_list.md`.
- Если PR затрагивает Go: выполнен `go mod tidy` в изменённых модулях и прогнаны `make lint-go` и `make dupl-go` (или `make lint`) с устранением нарушений.
- Для Go PR `make test-go` трактуется как герметичная unit/component проверка. PostgreSQL integration tests запускаются
  отдельно через `make test-go-postgres` или вместе с unit-контуром через `make test-go-all`.
- Если `make test-go-postgres` не запущен из-за отсутствия внешних DSN, Docker и Kubernetes test namespace/RBAC,
  это не записывается как дефект изменённого PR, но обязательно отмечается как незапущенная integration-проверка.
- Перед пушем выполнена повторная сверка с релевантными чек-листами и устранены все нарушения по размещению моделей/типов/констант/helper-кода.
