Andrey Epifancev afe40c70da openspec: архив nats-files-subjects (#74)
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
2026-10-08 23:50:10 +04:00

50 lines
4.5 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

## 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/` сервисов. Цена ошибки: при чтении истории встретятся старые имена.