# Исполнение единой нормализации ББ/ОФР — дорожная карта

Читать первым при продолжении работы. Источник истины по требованиям — спека этого change (`../specs/`, `../proposal.md`,
`docs/contracts/`, `docs/context/05-domain-rules.md` §7/§9/§11, `docs/model/data-model-v5.19.dbml`); по решениям — `../design.md`
(Р-1…Р-43 владельца, S-1…S-74 писателей спеки). Планы ниже аргументируют от спеки; при расхождении права спека.

## Планы

| № | Файл | Репозиторий | Задач | Ветка / worktree | Зависит от |
|---|---|---|---|---|---|
| 0 | `2026-10-18-plan-0-contract-identity.md` | arm-core, tabular-parser, scan-gateway (3 PR) | 5 | `feat/<issue>-contract-identity-window`, `.wt/contract-window/<repo>` | ничего |
| 1 | `2026-10-18-plan-1-arm-statements.md` | arm-statements (новый) | 19 | `feat/<issue>-arm-statements-package`, `.wt/normalization/arm-statements` | push `main` arm-statements |
| 2 | `2026-10-18-plan-2-sync-statements.md` | docs + 3 PR подключения в хостах | 9 | `feat/<issue>-sync-statements`, `.wt/sync-statements/docs`; хосты — `.wt/statements-adopt/<хост>` | PR плана 1 слит |
| 3А | `2026-10-18-plan-3-arm-core.md`, часть А | arm-core | 14 | `feat/<issue>-normalization-core-a`, `.wt/normalization-core-a/arm-core` | план 0 (для A5) |
| 3Б | тот же, часть Б | arm-core | 7 | `feat/<issue>-normalization-core-b`, `.wt/normalization-core-b/arm-core` | PR 3А и PR плана 2 в arm-core слиты |
| 4 | `2026-10-18-plan-4-tabular-parser.md` | tabular-parser (+ golden в fixtures) | 10 | `feat/<issue>-statements-v2`, `.wt/normalization-tp/tabular-parser` | планы 1, 2 |
| 5 | `2026-10-18-plan-5-scan-gateway.md` | scan-gateway (+ golden в fixtures) | 8 | `feat/<issue>-statements-v2`, `.wt/normalization-sg/scan-gateway` | планы 1, 2 |
| 6 | `2026-10-18-plan-6-arm-web.md` | arm-web (PR в `test`), затем `make -C docs sync-web` | 12 | `feat/<issue>-statements-v2`, `.wt/normalization-web/arm-web` | T1–T10 — по фикстуре сразу; T11 — после 3А |

## Волны

1. **Волна 1 (параллельно):** план 0 — три PR, слить **до** docs PR #117; план 1 — после push `main` arm-statements;
   план 3 часть А; план 6 задачи T0–T10.
2. **Волна 2:** план 2 (после PR плана 1) → затем планы 4, 5 и 3 часть Б (после подключения пакета к хостам).
3. **Финиш волны 2:** план 6 T11 (Playwright на стенде) после 3А, лучше вместе с 3Б.

Способ исполнения (глобальный CLAUDE.md): на каждую дорожку — фоновый SDD-контроллер **на модели sonnet**;
исполнители — модели, указанные в задачах плана; ревью всей ветки — opus. План ≤ 5 задач (план 0) — executing-plans.
В брифе контроллера: ждать task-notification, не циклы `sleep`; хук не обходить; находки — с маркерами и статусами
(`fixed <commit>` / `deferred` / `rejected`), таблица `## Findings` в ledger.

## Выкладка (proposal, «сначала ядро»)

0. Слиты PR плана 0 во всех трёх репозиториях.
1. Очистка форм ББ/ОФР на стенде: `api/scripts/purge_statements.py --dry-run` → решение владельца по смешанным файлам
   (Р-27) → `--apply`.
2. Ядро А + Б и фронт (план 6 + sync-web) выкладываются одним снимком (`JobBrief.warnings` меняет тип).
3. Слить docs PR #117 (контракт v2.0, DBML v5.19, спека); перед этим повторить проверку плана 0 на его последнем
   коммите.
4. Сервисы на 2.0: PR golden в fixtures и PR tabular-parser / scan-gateway сливаются только после выкладки ядра,
   golden — непосредственно перед своим сервисом.
5. После выкладки: архивация OpenSpec change'ей в каждом репозитории, follow-up issue по `deferred`.

## Предусловия и состояние на 18.10.2026

- RSHB/arm-statements создан; клон `awp-ca/arm-statements`, `main` локально: начальный README + `adopt-project.sh`.
  Push `main` делает владелец (хук guard-main): `git -C ~/projects/awp-ca/arm-statements push -u origin main`.
- Решения владельца по открытым вопросам планов — Р-31…Р-43 в `../design.md`; на прогоне реальных файлов неожиданный
  `needs_check` — стоп и вопрос владельцу (Р-31).
- Jira недоступна; что внести после — arm-ka-docs#118 (тестировщику — сразу после слияния, не ждать контур).

## Решения Р-31…Р-43 и планы

Решения приняты после написания планов и в тексты планов **не внесены** — контроллер дорожки обязан учесть их в
брифах исполнителей (а при расхождении с планом — следовать решению):

| Решение | План | Что учесть |
|---|---|---|
| Р-31 | 4, 5 | неожиданный `needs_check` на реальных файлах — стоп и вопрос владельцу, адаптер под файл не подгонять |
| Р-32, Р-33 | 5 | json без таблиц → `JSON_FAILED`; все json ошибочны → перечислить `JSON_FAILED` каждого, код файла — от первого |
| Р-34 | 1, 3, 6 | подтверждение кода — флаг `is_confirmed`, уверенность не меняется (уже внесено в спеку и планы сведением) |
| Р-35 | 3 (A4) | очистка отказывает только при `VERIFIED` / `ARCHIVED` со снимком ЕХ (уже внесено сведением) |
| Р-36 | 0, docs | в окне перехода новых примеров контракта верхнего уровня не добавлять |
| Р-37, Р-38 | 6 | экран принимается по фикстуре 2.0 + регрессия 1.x, прогон aep_3 — follow-up; подтверждённая ячейка — серая галочка |
| Р-39 | 4 | коды предупреждений ОСВ — по источнику `OSV_*` |
| Р-40 | 3 | `CODE_NOT_IN_DICTIONARY` / `CODE_NOT_IN_EDITION` — только четырёхзначные коды |
| Р-41 | 3 (A3) | смена `crm_id` ГСК/ГСЗ — в аудит как изменение группы |
| Р-42 | 2 | `sync-statements --check` в `prepare-contour-snapshot.sh` |
| Р-43 | 1 | `arm-statements` — в таблицу workspace (`CLAUDE.md` workspace, `context/00-workspace-layout.md`) |

Решения исполнителей планов P1-21…P1-31, P3-19…P3-24, P5-20 (появились при сведении API) переносятся в `../design.md`,
раздел «Decisions made without discussion», при исполнении соответствующего плана, вместе с остальными P-n.