Предложить классификацию финансовой операции

Ответ расширения на точку finance.classification_provider.v1. Запрос приезжает ему событием finance.transaction.uncategorized.v1 — минимальным снимком операции: сумма, дата, направление, назначение и контрагент ссылкой. Ни остатка по счёту, ни соседних операций, ни самого счёта в снимке нет: чтобы предложить статью, знать, сколько у кабинета денег, незачем.

РЕКОМЕНДАЦИЯ ЛОЖИТСЯ РЯДОМ С ОПЕРАЦИЕЙ И НЕ ПРИМЕНЯЕТСЯ. Этот вызов не меняет ни классификацию операции, ни движения регистров, ни документ: он пишет ровно одну строку — мнение установки. Статью проставляет человек штатной командой financeCategorizeTransaction, и до его нажатия операции нет ни в ДДС, ни в ОПиУ, ни в балансе. Так устроен основной поток ADR: асинхронный внешний результат сначала ложится проверкой, рекомендацией или черновиком, а окончательное действие выполняет команда Akeda.

ОБЛАСТЬ finance:suggest, а не finance:write. Это разные обещания на экране согласия: «предлагает, как разнести ваши операции» и «разносит ваши операции». Совпадение области проверяется точным равенством, поэтому finance:write эту дверь не открывает, а finance:suggest не открывает ни одной другой — ни чтения операций, ни классификации.

КАБИНЕТА В АДРЕСЕ НЕТ ни одним сегментом: он берётся из токена установки. Операция чужого кабинета отвечает 404 — тем же, чем несуществующая. Уже классифицированная операция отвечает 409: совет ей больше не нужен, а показанный рядом с решением человека он выглядел бы спором с ним.

ПОВТОР — ОБНОВЛЕНИЕ, А НЕ ВТОРАЯ СТРОКА. Доставка события повторяется, и приёмник обязан быть идемпотентным: ключ — естественная пара «операция + установка», у одной установки на одну операцию бывает ровно одно действующее мнение. Заголовок Idempotency-Key здесь не читается: он слабее — доставка webhook повторяется без него, — а точный повтор ответа ничего не даёт, потому что ответ не несёт ни секрета, ни новых сведений. Тот же ответ на уже отклонённую рекомендацию решения человека не отменяет; другая статья возвращает её в ожидание — это новое мнение, а не повтор старого.

Ссылки передаются парой «ключ справочника + идентификатор»: голый UUID может принадлежать другому справочнику или другому кабинету, и сервер проверяет и то, и другое.