# Индекс пакета для ИИ-агента по рефакторингу Control Plane

Этот пакет задает рабочий контракт для ИИ-агента, который будет поэтапно разносить текущий Control Plane на ограниченное число сервисов с четким владением кодом, данными и API.

Пакет собран на основе приложенного аналитического отчета по Control Plane и уточнений по целевому процессу:
- старую control-plane-модель не поддерживаем как отдельный продуктовый слой, но live-кластер уже существует: миграции, контракты, env/secrets/config и deploy path меняются только через safe staged sequence;
- нельзя накапливать двойные реализации надолго: если в PR добавили новый путь, старый путь нужно удалить в этом же PR или оформить короткий staged cutover с явным следующим срезом удаления;
- у каждого сервиса должна быть своя база данных в одном сервере или кластере Postgres, но с разными базами и разными credentials;
- ни один сервис не читает и не пишет данные другого сервиса напрямую в чужую БД - только через gRPC API сервиса-владельца;
- в начале работы агент обязан проанализировать текущее состояние GitHub Issues и скорректировать план;
- в каждом подэтапе вместе с кодом обязательно обновляется продуктовая документация и все связные markdown-файлы.

## Порядок чтения

1. `00-agent-mandate.md` - обязательные правила и ограничения.
2. `01-executive-context.md` - сжатый контекст по проблеме.
3. `02-target-architecture.md` - целевая архитектура и границы.
4. `03-service-boundaries.md` - каталог сервисов и ownership.
5. `04-data-ownership-and-grpc.md` - правила по БД, gRPC и обмену данными.
6. `05-roadmap-and-stages.md` - этапы работ и порядок выноса доменов.
7. `06-issues-audit-and-sync.md` - обязательный аудит Issues перед стартом и перед каждым следующим этапом.
8. `07-pr-playbook.md` - правила для каждого PR и критерии готовности.
9. `08-templates.md` - шаблоны для ADR, сервиса, PR и Issues.
10. `99-source-report.md` - исходный аналитический отчет, на котором основан пакет.

## Как агент должен работать

1. Сначала провести аудит open Issues, active PRs и текущей реализации в репозитории.
2. На основе аудита обновить дорожную карту из `05-roadmap-and-stages.md` и карту Issues из `06-issues-audit-and-sync.md`.
3. Дальше идти только вертикальными срезами: один bounded context за раз.
4. В каждом PR менять все вызовы до конца сценария и удалять старый код в том же PR.
5. После каждого этапа обновлять документацию продукта, архитектурные markdown-файлы, ADR и связанные Issues.

## Целевой результат

В репозитории не должно остаться "скрытого монолита" под видом нескольких папок. Должны получиться несколько сервисов с понятными границами:
- владелец домена;
- владелец схемы данных;
- владелец gRPC контракта;
- отдельный набор миграций;
- отдельные credentials к своей БД;
- понятный каталог документации.

## Состав пакета

- `00-agent-mandate.md`
- `01-executive-context.md`
- `02-target-architecture.md`
- `03-service-boundaries.md`
- `04-data-ownership-and-grpc.md`
- `05-roadmap-and-stages.md`
- `06-issues-audit-and-sync.md`
- `07-pr-playbook.md`
- `08-templates.md`
- `templates/ADR_TEMPLATE.md`
- `templates/ISSUE_TEMPLATE.md`
- `templates/PR_TEMPLATE.md`
- `templates/SERVICE_SPEC_TEMPLATE.md`
- `99-source-report.md`
