Change слит PR #77; спеки обновлены (subject'ы files.tabular_uploaded, files.img_uploaded, files.tabular_parsed). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012vJkmBGKKqMoEMzvsXG3y2
50 lines
4.5 KiB
Markdown
50 lines
4.5 KiB
Markdown
## 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/` сервисов. Цена ошибки: при чтении истории встретятся старые имена.
|