---
doc_id: PRC-CK8S-0001
type: process-requirements
title: "kodex — Development and Documentation Process Requirements"
status: active
owner_role: EM
created_at: 2026-02-06
updated_at: 2026-04-21
related_issues: [1, 112, 210, 212, 241, 243, 327, 397]
related_prs: []
approvals:
  required: ["Owner"]
  status: approved
  request_id: "owner-2026-02-19-full-docset"
  approved_by: "ai-da-stas"
  approved_at: 2026-02-19
---

# Development and Documentation Process Requirements

## TL;DR
- Этот документ задаёт обязательный weekly-процесс: планирование спринта, ежедневное выполнение, ежедневный deploy на production, закрытие спринта.
- Требования обязательны для разработки и для ведения документации.
- Любое отклонение от процесса фиксируется явно и согласуется с Owner.
- Для Issue/PR действует единый стандарт заголовков и содержимого, зависящий от stage и роли агента.
- Проектная документация ведётся по фиксированной карте размещения (`product/architecture/delivery/ops/templates`) без смешения типов документов.
- Для approval PR документ сразу публикуется в целевом финальном статусе; merge PR считается фактом согласования.
- Production-ориентированные изменения должны поставляться компактными PR; быстрый прототип не заменяет последующую production-декомпозицию.

## Нормативные ссылки (source of truth)
- `AGENTS.md`
- `docs/product/requirements_machine_driven.md`
- `docs/product/constraints.md`
- `docs/product/agents_operating_model.md`
- `docs/product/labels_and_trigger_policy.md`
- `docs/product/stage_process_model.md`
- `docs/delivery/delivery_plan.md`
- `docs/delivery/sprints/s1/sprint_s1_mvp_vertical_slice.md`
- `docs/delivery/sprints/s2/sprint_s2_dogfooding.md`
- `docs/delivery/sprints/README.md`
- `docs/delivery/epics/README.md`
- `docs/delivery/e2e_mvp_master_plan.md`
- `docs/delivery/issue_map.md`
- `docs/delivery/requirements_traceability.md`
- `docs/delivery/traceability/README.md`
- `docs/design-guidelines/**`
- `docs/templates/**`

## Базовые принципы процесса
- Weekly sprint cadence: каждая неделя начинается формальным kickoff и завершается formal close.
- Trunk-based delivery: маленькие инкременты, ежедневные merge в `main`.
- CI/CD discipline: merge только после green pipeline и обязательного deploy в production.
- Docs-as-code: изменения кода и документации синхронны в одном рабочем цикле.
- Traceability by default: каждое решение привязано к требованиям и артефактам.
- Security by default: секреты не хранятся в репозитории, префикс переменных платформы `KODEX_`.
- Русскоязычная документация и PR пишутся по-русски; английский используется только там, где это необходимо для точного технического смысла.
- Compact PR by default: один PR должен закрывать один понятный срез, а не смешивать несколько больших направлений.
- Прототип допустим как быстрый инструмент проверки идеи, но production-путь обязан быть разложен на последовательность компактных PR.
- Owner утверждает документы, архитектурные и risk/release решения; обязательный построчный review каждого PR самим Owner не является требованием процесса.

## Роли и ответственность

| Роль | Ответственность | Основные артефакты |
|---|---|---|
| Owner | Утверждает scope, приоритеты, критические решения, go/no-go | Апрувы в frontmatter, решения по рискам |
| PM | Поддерживает продуктовые требования и ограничения | `docs/product/requirements_machine_driven.md`, `docs/product/brief.md`, `docs/product/constraints.md` |
| EM | Ведёт спринт-план, эпики, daily delivery gate | `docs/delivery/sprints/s*/sprint_s*.md`, `docs/delivery/epics/s*/epic_s*.md`, `docs/delivery/epics/s*/epic-s*-day*.md` |
| SA | Архитектурная и data-model консистентность | `docs/architecture/*.md`, миграционная стратегия |
| Dev | Реализация задач и технические проверки | код, тесты, миграции, изменения API/контрактов |
| Reviewer | Предварительное ревью PR до Owner | inline findings в PR + summary для Owner |
| QA | Ручной smoke/regression на production, acceptance evidence | test evidence, regression checklist |
| SRE | Bootstrap/deploy/runbook/операционная устойчивость | bootstrap scripts, deploy manifests, runbook |
| KM | Трассируемость документации и актуальность карты связей | `docs/delivery/issue_map.md`, `docs/delivery/requirements_traceability.md`, `docs/delivery/traceability/README.md` |

Уточнение по review-модели:
- Owner не рассматривается как обязательный line-by-line reviewer каждого изменения кода.
- Техническое ревью, QA и эксплуатационные проверки распределяются по risk-gates между `reviewer`, `QA`, `SRE` и другими профильными участниками процесса.
- Для high-risk изменений обязательный human approval сохраняется, но он должен быть основан на риск-классе и evidence package, а не на привычке проверять весь код вручную.

## Нейминг артефактов (обязателен)

Цель: чтобы ссылки в документации были стабильными и чтобы каждый спринт имел однозначные файлы.

Правила:
- Sprint plan файл:
  - `docs/delivery/sprints/s<номер>/sprint_s<номер>_<краткое-имя>.md`
  - пример: `docs/delivery/sprints/s2/sprint_s2_dogfooding.md`
- Epic catalog файл:
  - `docs/delivery/epics/s<номер>/epic_s<номер>.md`
  - пример: `docs/delivery/epics/s2/epic_s2.md`
- Daily epic docs:
  - `docs/delivery/epics/s<номер>/epic-s<номер>-day<день>-<краткое-имя>.md`
  - пример: `docs/delivery/epics/s2/epic-s2-day0-control-plane-extraction.md`

## Стандарт заголовков и содержимого Issue/PR (обязателен)

Цель: заголовок и body должны сразу показывать stage, роль и тип результата.

Канонический source-of-truth для agent-generated title/body contract:
- `docs/delivery/development_process_requirements.md`
- `services/jobs/agent-runner/internal/runner/templates/prompt_blocks/issue_contract_<locale>.tmpl`
- `services/jobs/agent-runner/internal/runner/templates/prompt_blocks/pr_contract_<kind>_<locale>.tmpl`

Базовое правило: delivery-документация и prompt contract blocks обновляются синхронно в одном PR.
Исключение допускается только для markdown-only trigger, который не разрешает менять prompt files:
в таком случае documentation PR обязан явно зафиксировать follow-up issue на синхронизацию prompt contract blocks.

### Заголовки

#### Stage issue для kickoff/backlog

| Тип | Формат | Пример |
|---|---|---|
| Stage issue (doc stages) | `S<спринт> Day<день>: <Stage> для <краткая цель>` | `S7 Day1: Intake для закрытия MVP readiness gaps` |
| Stage issue (`run:dev`) | `S<спринт> Day<день>: Dev — <краткая реализация>` | `S6 Day7: Dev — lifecycle управления агентами и prompt templates` |

#### Follow-up / handover Issue, который создаёт агент

| Роль / сценарий | Формат | Пример |
|---|---|---|
| `dev` | `Dev follow-up[ Sprint S<спринт> Day<день>]: <краткий технический пробел или следующий шаг>` | `Dev follow-up Sprint S7 Day6: добавить шаблонный контракт оформления PR` |
| `qa` | `QA gap[ Sprint S<спринт> Day<день>]: <краткий дефект, сценарий или пробел проверки>` | `QA gap Sprint S7 Day8: покрыть DNS-path smoke для новых ручек` |
| `sre` | `SRE remediation[ Sprint S<спринт> Day<день>]: <краткая инфраструктурная проблема или действие>` | `SRE remediation Sprint S6 Day11: закрепить rollback шаг для runtime deploy` |
| `reviewer` | `Review follow-up[ Sprint S<спринт> Day<день>]: <краткий риск или блокер>` | `Review follow-up Sprint S7 Day7: убрать дрейф между prompt contract и process doc` |
| Другие роли (`pm`, `sa`, `em`, `km`) | `<agent_key>[ Sprint S<спринт> Day<день>]: <краткая цель, решение или пробел>` | `km Sprint S10 Day6: синхронизировать title-contract с prompt policy` |

#### PR, который публикует агент

| Роль / сценарий | Формат | Пример |
|---|---|---|
| doc-stage роли (`pm`, `sa`, `em`, `km`) | `Issue #<номер>: <stage>-package — <краткая цель пакета>` | `Issue #397: doc-audit-package — актуализировать contract заголовков` |
| `run:dev` | `Issue #<номер>: <краткий технический результат> (#<номер>)` | `Issue #199: реализация lifecycle управления агентами и шаблонами промптов (#199)` |
| `run:qa` | `Issue #<номер>: qa[ Sprint S<спринт> Day<день>] — <краткий итог проверки> (#<номер>)` | `Issue #201: qa Sprint S6 Day8 — regression GO по lifecycle agents/prompts (#201)` |
| `run:ops` / `run:release` / `run:postdeploy` / `run:ai-repair` под ролью `sre` | `Issue #<номер>: sre[ Sprint S<спринт> Day<день>] — <краткий итог remediation> (#<номер>)` | `Issue #265: sre Sprint S6 Day11 — operational baseline и rollback readiness (#265)` |

Обязательные правила для заголовков:
- заголовок всегда одной строкой и без точки в конце;
- сначала фиксируется предмет/результат, потом уточнение;
- расплывчатые формулировки (`misc`, `update`, `fixes`, `wip`, `changes`) без предмета запрещены;
- если заголовок явно содержит роль агента, то при наличии stage context сразу после role token добавляется фрагмент `Sprint S<спринт> Day<день>`;
- если sprint/day для конкретного follow-up или PR не зафиксированы, этот фрагмент опускается целиком;
- если артефакт связан с существующей задачей, заголовок обязан сохранять прямую связь с `Issue #<номер>`.

### Follow-up Issue body

Для follow-up Issue использовать exact `##`-секции:
- `## Контекст`
- `## Проблема`
- `## Почему это важно сейчас`
- `## Что требуется сделать`
- `## Acceptance Criteria`
- `## Риски и ограничения`
- `## Связанные артефакты`

Дополнительно для QA-gap/failure issue:
- `## Сценарии воспроизведения / тестовые шаги`

Правила:
- если раздел не применим, писать `Не требуется`;
- в `Связанные артефакты` указывать issue/PR/doc/run/environment ссылки;
- для follow-up issue роль должна быть видна уже из заголовка (`Dev follow-up`, `QA gap`, `SRE remediation`, `Review follow-up` или `<agent_key>`);
- при наличии sprint/day в role-bearing title сначала идёт role token, затем `Sprint S<спринт> Day<день>`, и только после этого `:` с предметом задачи.

Пример follow-up Issue title:
- `km Sprint S10 Day6: синхронизировать title-contract с prompt policy`

### PR body: базовый контракт

| Артефакт | Обязательные блоки |
|---|---|
| Issue (любой stage) | `Контекст`, `Проблема`, `Scope (in/out)`, `Acceptance Criteria`, `Риски/допущения`, `Next stage handover` |
| PR для doc-stage (`run:intake..run:plan`, `run:qa`, `run:release`, `run:postdeploy`, `run:ops`, `run:doc-audit`) | `Контекст stage/role`, `Что обновлено`, `Traceability`, `Проверки`, `Риски`, `Next action` |
| PR для `run:dev` | `Контекст`, `Что изменено (code+docs)`, `Проверки (tests/lint/build)`, `Риски/миграции`, `Traceability` |

Общие правила для любого PR body:
- body должен быть валидным Markdown;
- использовать exact `##`-секции в порядке, определённом role/stage prompt contract;
- в каждом разделе писать факты: команды, тесты, запросы, логи, файлы, окружения, а не общие формулировки;
- если проверка, просмотр логов, работа с БД или чек-лист не выполнялись, это должно быть указано явно;
- в разделе закрытия последней строкой должен стоять exact directive:
  `Closes https://github.com/<owner>/<repo>/issues/<номер>`;
- short form `Closes #<номер>` допустим только если платформа работает в том же репозитории, но каноническим форматом для cloud agents считается полная ссылка.

### Политика согласования документов
- Документ, который входит в PR на принятие, сразу публикуется в целевом финальном состоянии.
- В approval PR не использовать внутри самого документа статусы `pending approval`, `in-review`, `ожидает согласования` и аналогичные формулировки.
- Merge PR является фактом согласования документа и закрепляет frontmatter без отдельного post-merge редактирования.

### Политика размера PR и перехода от прототипа к production
- Большой прототип не должен напрямую становиться production baseline.
- После подтверждения идеи обязателен отдельный цикл production conversion:
  - зафиксировать целевую модель;
  - разбить переход на последовательность компактных PR;
  - убрать временные решения и скрытые швы по мере продвижения.
- Для production-ориентированных PR приоритетны:
  - ясный доменный scope;
  - понятный список удаляемого legacy;
  - ограниченный объём diff, который реально можно проверить.

### PR body: role-specific детализация

Для `run:dev`:
- `## Контекст`
- `## Основание для изменений`
- `## Основной смысл правок`
- `## Что сделано`
- `## Логи и runtime-диагностика`
- `## БД и миграции`
- `## Проверки`
- `## Проверенные чек-листы`
- `## Риски и ограничения`
- `## Рекомендации / следующий шаг`
- `## Закрытие`

Пример PR title для `run:dev`:
- `Issue #253: вынести prompt-контракты в шаблоны (#253)`

Для `run:dev:revise` и других `run:*:revise`:
- существующие PR title и body из исходной implementation-итерации сохраняются; revise-цикл не должен переименовывать или перетирать уже опубликованный контекст, трассируемость и историю проверок;
- перед обновлением PR title/body нужно сначала получить текущее название и описание существующего PR и только после этого встраивать revise-заметки поверх них;
- заголовок существующего PR сохраняется без изменения; допустима только минимальная правка, если заголовок потерял связь с `Issue #<номер>` или стал фактически некорректным;
- секции ниже описывают append-блок revise-итерации, который добавляется в конец текущего body перед финальным `## Закрытие`, а не заменяет весь body целиком;
- `## Контекст ревизии`
- `## Основание для изменений`
- `## Какие замечания обработаны`
- `## Какие замечания отклонены и почему`
- `## Что изменено`
- `## Повторные проверки`
- `## Проверенные чек-листы`
- `## Риски и ограничения`
- `## Рекомендации / следующий шаг`
- `## Закрытие`
- если в текущем body уже есть `## Закрытие`, финальный блок нужно перенести/обновить так, чтобы directive `Closes https://github.com/<owner>/<repo>/issues/<номер>` снова был последней строкой PR body;

Пример поведения для revise-итерации:
- сохранить существующий заголовок PR и дополнить только body новым revise-блоком

Для `run:qa`:
- `## Контекст`
- `## Основание для изменений`
- `## Что тестировалось`
- `## Тестовые сценарии и запросы`
- `## Где проверялось`
- `## Логи и evidence`
- `## Проверки`
- `## Проверенные чек-листы`
- `## Риски и ограничения`
- `## Рекомендации / следующий шаг`
- `## Закрытие`

Для `run:ops`, `run:release`, `run:postdeploy`, `run:ai-repair`:
- `## Контекст`
- `## Основание для изменений`
- `## Что диагностировано`
- `## Логи и инфраструктурная диагностика`
- `## Изменения в инфраструктуре`
- `## Rollback / mitigation`
- `## Проверки`
- `## Проверенные чек-листы`
- `## Риски и ограничения`
- `## Рекомендации / следующий шаг`
- `## Закрытие`

Для doc-stage ролей (`pm`, `sa`, `em`, `km`):
- `## Контекст stage/role`
- `## Основание для изменений`
- `## Что обновлено в артефактах`
- `## Traceability`
- `## Проверки`
- `## Проверенные чек-листы`
- `## Риски и ограничения`
- `## Рекомендации / следующий шаг`
- `## Закрытие`

Для reviewer-run:
- новый PR не создаётся;
- review summary оформляется в существующем PR с exact секциями:
  - `## Findings`
  - `## Evidence`
  - `## Проверенные guides/checklists`
  - `## Blocking / non-blocking`

## Информационная архитектура документации (обязательна)

| Каталог | Что хранится | Запрещено смешивать |
|---|---|---|
| `docs/product/` | продуктовые требования, роли, labels/stage policy, charter/brief/constraints | delivery-планы, day-эпики, runbooks |
| `docs/architecture/` | C4, ADR, API/data model, RBAC/prompt policy, design alternatives | спринт-план и release backlog |
| `docs/delivery/` | delivery plan, sprint/epic документы, issue map, requirements traceability, traceability history packages, process requirements | дублирование product source-of-truth и архитектурных контрактов |
| `docs/ops/` | production runbooks и эксплуатационные инструкции | stage-планирование и product scope |
| `docs/templates/` | канонические markdown-шаблоны документов | фактические артефакты этапов вместо шаблонов |

Правила:
- Один документ описывает одну цель и один уровень абстракции.
- Если документ описывает процесс/политику, он должен ссылаться на source-of-truth документ более высокого уровня.
- Канонический root navigation path проекта: `docs/index.md`.
- В каждом доменном каталоге `docs/<domain>/` обязателен `README.md` с картой source-of-truth документов и вложенных подпапок.
- Инициативные/stage-specific пакеты и handover-наборы размещаются в специализированных подпапках, а не на корне домена:
  - для архитектурных инициатив использовать `docs/architecture/initiatives/<slug>/`;
  - для эксплуатационных handover-пакетов использовать `docs/ops/handovers/<slug>/`;
  - для delivery уже закреплены специализированные подпапки `docs/delivery/sprints/`, `docs/delivery/epics/` и `docs/delivery/traceability/`.
- Delivery traceability делится по уровням абстракции:
  - `docs/delivery/issue_map.md` = current-state master-index по связям issue/pr/doc/status;
  - `docs/delivery/requirements_traceability.md` = стабильная FR/NFR-матрица текущего состояния;
  - `docs/delivery/traceability/s<номер>_*.md` = historical evidence и delta по спринтам.
- `docs/templates/` содержит только шаблоны и инструкции по их применению; проектные индексы, handover-пакеты и фактические source-of-truth документы туда не помещаются.
- Любой перенос документов выполняется только по явной migration-map с форматом
  `old path -> new path -> owner_role -> affected links/issues -> migration note`.
- В том же PR, где меняются пути документов, обязательно синхронно обновляются:
  - `services.yaml/spec.projectDocs`;
  - `services.yaml/spec.roleDocTemplates` (если затронуты шаблоны);
  - внутренние markdown-ссылки;
  - `docs/delivery/issue_map.md`;
  - `docs/delivery/requirements_traceability.md`;
  - `docs/delivery/traceability/README.md` и релевантный `docs/delivery/traceability/s<номер>_*.md` (если меняется historical evidence);
  - открытые GitHub issues/PR, где использовались старые doc-path или branch-specific blob links.
- Любой новый документ сразу добавляется в релевантный индекс (`delivery/sprints/README.md`, `delivery/epics/README.md`, `issue_map`, `requirements_traceability`, `traceability/README.md`).

## Ролевая матрица шаблонов документов (обязательна)

Эта матрица обязательна не только для людей, но и для runtime-конфигурации:
- `services.yaml/spec.roleDocTemplates` должен оставаться синхронным с таблицей ниже;
- `services.yaml/spec.projectDocs` должен давать роли доступ к релевантным source-of-truth каталогам;
- любые расхождения считаются documentation governance drift и исправляются в том же PR.

| Роль | Основные stage | Обязательные шаблоны (`docs/templates/*.md`) |
|---|---|---|
| PM | `run:intake`, `run:vision`, `run:prd` | `problem.md`, `scope_mvp.md`, `constraints.md`, `brief.md`, `project_charter.md`, `success_metrics.md`, `prd.md`, `nfr.md`, `user_story.md` |
| EM | `run:plan`, `run:release`, `run:release:revise` | `delivery_plan.md`, `epic.md`, `definition_of_done.md`, `release_plan.md`, `release_notes.md`, `rollback_plan.md` |
| SA | `run:arch`, `run:design` | `c4_context.md`, `c4_container.md`, `adr.md`, `alternatives.md`, `api_contract.md`, `data_model.md`, `design_doc.md`, `migrations_policy.md` |
| Dev | `run:dev` | `user_story.md`, `definition_of_done.md` + обязательная синхронизация traceability-доков |
| QA | `run:qa`, `run:qa:revise`, `run:postdeploy`, `run:postdeploy:revise` | `test_strategy.md`, `test_plan.md`, `test_matrix.md`, `regression_checklist.md`, `postdeploy_review.md` |
| SRE | `run:ops`, `run:ops:revise`, `run:release`, `run:release:revise`, `run:postdeploy`, `run:postdeploy:revise`, `run:ai-repair` | `runbook.md`, `monitoring.md`, `alerts.md`, `slo.md`, `incident_playbook.md`, `incident_postmortem.md` |
| KM | cross-stage traceability, `run:doc-audit`, `run:doc-audit:revise`, `run:self-improve`, `run:self-improve:revise` | `issue_map.md`, `delivery_plan.md`, `roadmap.md`, `docset_issue.md`, `docset_pr.md` |
| Reviewer | pre-review (`need:reviewer`) | шаблоны не генерирует; публикует findings/commentary в PR |

## Еженедельный цикл спринта

### 1. Sprint Start (день начала недели)
- Проверить актуальность требований и ограничений.
- Сформировать/актуализировать план спринта и набор эпиков по дням.
- Для каждого эпика задать priority (`P0/P1/P2`) и ожидаемые артефакты дня.
- Провести DoR-check.

Обязательные артефакты:
- Sprint plan: `docs/delivery/sprints/s<номер>/sprint_s<номер>_<краткое-имя>.md` (актуальный sprint-file недели).
- Epic catalog: `docs/delivery/epics/s<номер>/epic_s<номер>.md` и daily epic docs в `docs/delivery/epics/s<номер>/`.
- `docs/delivery/issue_map.md` и `docs/delivery/requirements_traceability.md`.

### 2. Daily Execution (каждый рабочий день спринта)
- Реализовать задачи текущего дневного эпика.
- Выполнить merge в `main`.
- Подтвердить автоматический deploy на production.
- Выполнить ручной smoke-check и зафиксировать результат.
- Обновить документацию при изменении API/data model/webhook/RBAC/процессов.
- Для `run:qa` и `run:qa:revise` проверять новые/изменённые ручки через DNS Kubernetes namespace (service-to-service path), без блокировки на интерактивный OAuth browser-flow.

Daily gate (must pass):
- PR/merge только при green CI.
- Production deployment успешен.
- Smoke-check успешен или заведен блокер с решением.
- Документация синхронизирована.

### 2.1 Mainline Hygiene для `run:dev` и `run:dev:revise` (обязательно)
- Цель: детерминированно синхронизировать рабочую PR-ветку с `main` перед каждой revise-итерацией и исключить скрытые conflict-markers.
- Область применения:
  - все `run:dev` implementation PR;
  - обязательно для Sprint S7 execution issue-потоков `#243..#260`.
- Перед каждым push в открытую PR-ветку выполняется единый порядок:
  1. `git fetch origin --prune`
  2. `git checkout <pr-branch>`
  3. `git rebase origin/main`
  4. При конфликте: разрешить конфликт, `git add <file>`, `git rebase --continue`; при невозможности корректно разрешить конфликт — `git rebase --abort`, зафиксировать блокер и не пушить частично конфликтное состояние.
  5. Проверить отсутствие conflict-markers в рабочем дереве: `rg -n '^(<<<<<<<|=======|>>>>>>>)' .`
  6. Выполнить релевантные проверки (tests/lint/build/doc checks) в рамках scope PR.
  7. Публиковать rewritten историю только через `git push --force-with-lease origin <pr-branch>`.
- Запрещено:
  - делать `git merge origin/main` в рабочую PR-ветку для revise-итераций;
  - использовать `git push --force` вместо `--force-with-lease`;
  - открывать/обновлять review gate при найденных conflict-markers.
- Обязательный rebase-checklist для PR body:
  - [ ] Ветка синхронизирована с актуальным `origin/main` через `git rebase origin/main`.
  - [ ] Проверка `rg -n '^(<<<<<<<|=======|>>>>>>>)' .` не нашла conflict-markers.
  - [ ] После rebase повторно выполнены релевантные проверки по scope PR.
  - [ ] Публикация обновлённой истории выполнена через `git push --force-with-lease`.

### 3. Mid-Sprint Control (середина недели)
- Перепроверить риски, блокеры, зависимости.
- Разрешается перераспределение `P1/P2`; `P0` меняется только через явное решение Owner.
- Актуализировать эпики и sprint-plan.

### 4. Sprint Close (последний день недели)
- Прогнать regression ключевых сценариев.
- Зафиксировать go/no-go на следующий спринт.
- Закрыть/перенести незавершённые задачи с обоснованием.
- Обновить roadmap/delivery-план.

## Матрица артефактов: кто и когда производит

| Артефакт | Когда | Кто производит (R) | Кто утверждает (A) |
|---|---|---|---|
| Requirements baseline | При изменении scope/решений | PM | Owner |
| Sprint plan | В начале недели и при major reprioritization | EM | Owner |
| Epic docs по дням | До старта дня и при закрытии дня | EM + Dev/SA/SRE | Owner |
| Data model updates | При любом изменении схемы/индексов | SA + Dev | Owner |
| API contract updates | При изменении внешних/внутренних API | SA + Dev | Owner |
| Issue/Doc traceability | Ежедневно после merge | KM + EM | Owner |
| Smoke/Regression evidence | Ежедневно / в конце спринта | QA + Dev | EM |
| Runbook/deploy updates | При изменении bootstrap/deploy/ops поведения | SRE + Dev | Owner |

## Обязательные quality gates
- Planning gate: DoR пройден, приоритеты и артефакты на день назначены.
- Mainline hygiene gate: рабочая PR-ветка ребейзнута на актуальный `origin/main`, conflict-markers отсутствуют, rewritten history опубликована только через `--force-with-lease`.
- Merge gate: green CI + обязательные проверки по risk-class + синхронная документация.
- Deploy gate: production deployment success + ручной smoke.
- Close gate: regression pass + согласованный backlog следующего спринта.

### Risk-oriented review baseline
- Для каждого крупного направления рефакторинга и для каждого production-slice должен определяться risk-class.
- Базовая шкала:
  - `R0`: docs-only, naming, governance без исполняемой логики;
  - `R1`: локальный код без изменения контрактов, данных и runtime policy;
  - `R2`: бизнес-логика, provider semantics, data model, runtime behavior;
  - `R3`: auth, токены, destructive ops, release gates, production DB/cluster impact.
- Для `R2` и `R3` обязательны дополнительные technical/human gates, состав которых фиксируется в доменной документации.

## Правило разрешения противоречий
- Если задача противоречит `docs/design-guidelines/**` или source-of-truth требованиям, работа останавливается.
- Предлагаются варианты решения с trade-offs.
- Финальное решение фиксируется в документации и утверждается Owner.

## Апрув
- request_id: owner-2026-02-06-process
- Решение: approved
- Комментарий: Процесс weekly sprint и doc governance утверждён.
