## Context

Решение владельца 08.10.2026: subject'ы NATS — как в старом АРМ. На проде заведены `files.img_uploaded`,
`files.img_parsed`, `files.tabular_uploaded`, `files.tabular_parsed`; владелец: «можно использовать три топика, давай
будем использовать только tabular_parsed. старый арм мы погасим».

| Поток | Было | Стало |
|---|---|---|
| запрос `tabular` | `recognition.tabular.request` | `files.tabular_uploaded` |
| запрос `image` | `recognition.image.request` | `files.img_uploaded` |
| ack и результат (оба сервиса) | `recognition.result` | `files.tabular_parsed` |

Схема обмена не меняется: два subject'а запроса по `pipeline` и один общий subject ответа, на который ядро подписано
queue group `arm-core`. Сопоставление ответа с заданием — по `job_id` и `Nats-Msg-Id`, не по subject.

## Goals / Non-Goals

Goals: переименовать subject'ы во всех трёх сервисах и в документах, не меняя тел сообщений и поведения.
Non-goals: см. proposal.

## Decisions

1. Общий subject ответа — `files.tabular_parsed` для обоих сервисов (прямое указание владельца). Имя исторически
   «табличное», но смысл у нас — «ответ сервиса распознавания»; это оговорено в `03-architecture.md`.
2. Старый АРМ гасится (владелец) — двойной доставки запроса в обработчики старого АРМ (`armka_file_worker`) не будет.

## Risks / Trade-offs

- Если старый АРМ не погасят к выкату, его обработчики получат копию каждого запроса (в core NATS каждая queue group
  получает своё сообщение): файл уйдёт в ИС Сканирование дважды, в `files.tabular_parsed` придут ответы чужого формата
  (ядро отбросит их по схеме с записью в лог).
- Выкат сервисов не по одному: сервис со старыми именами не увидит запросов ядра с новыми.

## Decisions made without discussion

1. 08.10.2026 — **R-1:** маршрут — OpenSpec change в каждом из четырёх репозиториев (требования спек называют
   subject'ы, спека — источник истины), код — по `.bounded` без плана SDD (механическое переименование констант).
   Цена ошибки: низкая, процессная.
2. 08.10.2026 — **R-2:** `schema_version` не меняется. Требование «Версионирование контракта» относится к полям тел
   сообщений; тела не меняются, subject'ы — часть окружения. Цена ошибки: низкая — потребители не различают версии
   по subject'у.
3. 08.10.2026 — **R-3:** DBML v5.17 не поднимается ради двух заметок (`DECISION-4` в шапке, note колонки
   `recognition_job.request_subject`): структура не меняется, а новая версия тянет копию модели, `entities`, ссылки в
   `CLAUDE.md` сервисов и `04-data-model-guide.md`. Заметки обновить в следующей версии DBML — **deferred**. Цена
   ошибки: до следующей версии заметки в DBML называют старые subject'ы.
4. 08.10.2026 — **R-4:** subject'ы остаются константами в `api/src/contract/subjects.py`, в настройки не выносятся
   (OQ-83 — отдельно). Цена ошибки: смена имён на платформе снова потребует релиза трёх сервисов.
5. 08.10.2026 — **R-5:** исторические записи не переписываются: строки OQ-69/OQ-83 в `07-open-questions.md`, архив
   OpenSpec, планы `docs/superpowers/plans/` сервисов. Цена ошибки: при чтении истории встретятся старые имена.