🔄 Change Protocol (10-step)

Версия: v1.0
Статус: Утверждён
Источник: ADR-003 (Core-first change protocol)

Обзор

Любое изменение конституции, доменной модели, архитектуры или продукта проходит строгий 10-шаговый протокол. Изменения, затрагивающие только код (баги, рефакторинг без изменения модели), могут пропускать шаги 1-4.

Шаг 1: Change Request

Что делать: Оформить запрос на изменение. Описать: что меняем, почему, какие документы и модули будут затронуты.

Кто отвечает: Инициатор (любой участник команды)

Артефакты: Заполненный CHANGE_REQUEST_TEMPLATE.md в pull request

Вход: Потребность в изменении (из opportunity, бага, запроса клиента)
Выход: Change Request документ

Пример: "Добавить поле warranty_months в Offer. EcoYar нужно указывать гарантию на станки."

Шаг 2: Classification

Что делать: Классифицировать изменение по типу и impact.

Типы изменений:

core_change — затрагивает доменную модель, конституцию, ADR
feature_add — новая функциональность в рамках существующей модели
bug_fix — исправление ошибки
refactor — рефакторинг без изменения поведения
docs — только документация

Impact:

H — затрагивает несколько BC, меняет модель данных, требует миграции
M — затрагивает один BC, новые сущности
L — только код/конфигурация

Кто отвечает: Product Architect + Tech Lead

Артефакты: Классификация в Change Request

Шаг 3: Impact Analysis

Что делать: Проанализировать влияние на:

Документы конституции (какие и как менять)
Модули/BC (какие и как)
Модель данных (новые поля, таблицы)
API (новые эндпоинты, изменения)
Другие системы (коннекторы)

Кто отвечает: Tech Lead

Артефакты: Impact analysis (секция в Change Request)

Шаг 4: Core Docs Update

Что делать: Обновить core-документы конституции в правильном порядке:

DOMAIN_GLOSSARY.md — новые термины или изменения определений
CORE_DOMAIN_MODEL.md — новые/изменённые сущности и связи
BOUNDED_CONTEXTS.md — если затрагиваются границы BC
SCOPE_MVP_V0_1.md — если меняется scope
ARCHITECTURE_PRINCIPLES.md — если нарушается/добавляется принцип

Кто отвечает: Product Architect

Артефакты: Изменения в core docs (в PR)

Шаг 5: ADR (если нужно)

Что делать: Если изменение затрагивает архитектуру, принципы или требует альтернатив — создать ADR.

Когда ADR обязателен:

Изменение доменной модели (добавление/удаление сущности)
Изменение связей между BC
Новый внешний интеграция
Изменение стека
Отклонение от принципов

Кто отвечает: Product Architect

Артефакты: ADR-NNN-name.md

Шаг 6: Task Card

Что делать: Создать детальную карточку задачи с:

Title и description
Goal (какую проблему решаем)
Acceptance criteria (проверяемые пункты)
Impacted modules (папки в apps/api)
Impacted entities (сущности из доменной модели)
Docs to update (список документов)
Estimated effort

Кто отвечает: Product Owner или инициатор

Артефакты: Task card (по TASK_TEMPLATE.md)

Шаг 7: Implementation (Code)

Что делать: Реализовать изменение в коде, следуя:

Domain-core separation (логика в domain слое)
Tenant isolation (все запросы с organization_id)
Принципы из ARCHITECTURE_PRINCIPLES.md
Commit convention (COMMIT_CONVENTION.md)

Кто отвечает: Разработчик

Артефакты: Код в feature branch

Шаг 8: Tests

Что делать: Написать тесты:

Unit tests для domain logic (обязательно)
Integration tests для repository (рекомендуется)
Edge cases: пустые данные, дубликаты, некорректные tenant_id

Кто отвечает: Разработчик

Артефакты: Тесты в feature branch

Покрытие: Core domain logic — минимум 80% покрытия.

Шаг 9: Changelog & Timeline

Что делать:

Обновить CHANGELOG.md с описанием изменения
Добавить запись в change-timeline.jsonl
Обновить DECISION_LOG.md если применимо

Кто отвечает: Разработчик (или архитектор для core изменений)

Артефакты: Обновления в changelog, timeline, decision log

Шаг 10: Review

Что делать: Провести ревью по REVIEW_CHECKLIST.md:

Architectural compliance — соответствует ли решение принципам?
Core-first — обновлены ли документы до кода?
Traceability — можно ли проследить от Vision до кода?
No magic fields — все поля описаны в доменной модели?
Tenant isolation — везде ли есть фильтр по организации?
Tests — достаточное покрытие?

Кто отвечает: Product Architect + Tech Lead

Артефакты: Review notes, approved/change-required

Диаграмма потока

Request → Classification → Impact → Core Docs → ADR → Task → Code → Tests → Changelog → Review
   │                                                              ↑                              │
   └──────────────────────────────────────────────────────────────┘                              │
   (если только код)                                                                             │
                                                                                                 ↓
                                                                                            Done ✓

Исключения

Bug fix (critical): Hotfix без протокола, но с обязательным post-factum ADR в течение 24 часов
Docs-only: Шаги 1, 6-8 пропускаются
Refactor (no model change): Шаги 1-5 пропускаются, changelog — опционально