# Аудит GitHub Issues и синхронизация плана

## Почему это обязательно

Без аудита backlog агент рискует:
- повторить уже начатую работу;
- пойти в конфликт с открытыми PR;
- закрепить неверный порядок этапов;
- оставить старые Issues, которые будут тянуть архитектуру назад.

Поэтому аудит Issues - это не побочная активность, а обязательный этап программы рефакторинга.

## Когда проводить аудит

Аудит делается:
- перед началом всей программы;
- перед началом каждого следующего этапа;
- после merge каждого этапного PR;
- перед закрытием эпика по домену.

## Что именно нужно проверить

### 1. Open Issues
Для каждого open issue определить:
- к какому bounded context он относится;
- он still relevant или уже устарел;
- это самостоятельная задача, подзадача этапа или дубликат;
- нужно ли изменить формулировку под новую архитектуру.

### 2. Active PRs
Для каждого активного PR определить:
- касается ли он затрагиваемого домена;
- не создает ли он новый hidden coupling;
- нужно ли его дождаться, перебазировать или закрыть;
- нужно ли перенести его scope в новый этап.

### 3. Recently closed Issues and PRs
Проверить, не изменилась ли уже фактическая архитектура относительно исходного отчета.

## Обязательная классификация

Каждый relevant issue должен быть размечен минимум по трем измерениям:
- domain: IAM / Projects / Runs / Runtime / Interactions / MissionControl / Cross-cutting
- phase: 0 / 1 / 2 / 3 / 4 / 5 / 6 / 7
- state: keep / rewrite / split / merge / close

## Результат аудита

После аудита должна появиться таблица такого вида:

| Issue | Domain | Decision | Target phase | Notes |
|---|---|---|---|---|
| #123 | Runtime | keep | 2 | already aligned |
| #124 | Cross-cutting | split | 1 and 5 | too broad |
| #125 | MissionControl | rewrite | 4 | update acceptance criteria |
| #126 | Legacy Control Plane | close | n/a | obsolete after new plan |

## Обязательные действия по итогам аудита

Агент обязан:
- обновить названия и описания Issues, если они зафиксированы в старой архитектурной модели;
- создать эпик на каждый этап, если эпиков нет;
- создать подзадачи на документацию внутри каждого этапа;
- создать подзадачи на удаление legacy-кода внутри каждого этапа;
- связать PR с issue tree;
- явно отметить задачи, которые закрываются самим фактом удаления старого кода.

## Правила актуализации Issues внутри этапа

В каждом этапном PR должны быть задачи минимум таких типов:
- service bootstrap
- proto and client cutover
- database creation and migrations
- legacy code removal
- docs update
- issue cleanup after merge

## Что считается плохим состоянием backlog

Плохое состояние backlog - это когда:
- есть задачи "вынести сервис" без перечисления legacy removal;
- есть задачи "обновить код" без подзадачи на docs;
- есть активные задачи, которые требуют доступа к shared DB после split;
- одна issue охватывает 2-3 bounded contexts без причины;
- закрытые задачи не отражены в документации.

## Ритуал после каждого merge

После merge этапного PR агент должен:
- закрыть выполненные Issues;
- перепривязать зависимые задачи к следующему этапу;
- обновить описание эпика;
- проверить, не появились ли новые hidden couplings;
- обновить roadmap markdown, если порядок этапов изменился.
