docs: reorganize system knowledge by domain

architecture/http-api.md

@@ -32,10 +32,13 @@ message/stack. Типичный ответ:
 не считается проверенным одним описанием OpenAPI: нужна проверка реального
 HTTP-ответа после всех стадий обработки запроса.
 
-**Требует ручной проверки:** согласованность деталей ошибок валидации полей
-в полном HTTP-потоке пока не подтверждена. Известно расхождение формата ошибок
-между стадиями валидации и формирования ответа; наличие описания в OpenAPI
-не доказывает передачу ожидаемых `pointer` и `detail`.
+**Известное расхождение:** согласованная
+[спецификация аутентификации](../../specs/openspec/specs/user-authentication/spec.md#requirement-стандартные-ответы-об-ошибках)
+требует `pointer` и `detail` для невалидных полей. В текущей конфигурации
+валидация формирует строковые сообщения, а фильтр ожидает структурированные
+ошибки полей; поэтому корректность деталей `errors` не подтверждена.
+Исправление требует отдельного изменения реализации и проверки полного
+HTTP-потока. OpenAPI сам по себе этого расхождения не устраняет.
 
 Ответ не включает автоматически все поля RFC (`type`, `title`, `instance`).
 Добавление обязательного поля является изменением публичного контракта.
@@ -45,9 +48,9 @@ HTTP-ответа после всех стадий обработки запро
 
 Специальный code определяется сценарием; общее преобразование ошибок и безопасная
 форма ответа принадлежат HTTP-границе. Auth endpoints используют свои status и cookie
-operations: [Authentication](../features/authentication.md).
+operations: [Authentication](../domains/authentication/overview.md).
 T-Bank token failure и временная недоступность имеют разные значения:
-[Connection API](../features/tbank-connection.md#api). Raw upstream/Prisma errors
+[Connection API](../integrations/tbank.md#состояние-и-ошибки). Raw upstream/Prisma errors
 и secrets не передаются frontend.
 
 ## Граница доказательства
@@ -57,4 +60,25 @@ T-Bank token failure и временная недоступность имеют
 Валидация, доступ, статусы и cookie требуют проверки полного HTTP-потока;
 атомарность хранения — проверки с изолированной реальной базой.
 Известное ограничение сквозных проверок описано в
-[проверке backend](../development/backend-workflow.md#локальная-проверка).
+[проверке backend](../development/verification.md).
+
+## Наблюдаемость
+
+Backend пишет структурированные JSON-события в stdout через Pino. Обработка
+HTTP-запроса получает серверный request ID, который возвращается заголовком
+`X-Request-ID`; допустимый входящий идентификатор сохраняется отдельно как
+client request ID. Это позволяет сопоставить публичную ошибку с обработкой
+запроса без передачи внутреннего exception в ответ API.
+
+Журнал завершения запроса содержит шаблон маршрута, метод, статус,
+длительность и при наличии публичный error code. События внешней границы
+добавляют операцию, результат и число попыток. Разрешённые поля ограничены;
+полные запросы и ответы, token, cookie и Authorization не являются данными
+журнала. Фильтрация полей и redaction не защищают секрет, вручную включённый
+в свободный текст сообщения или stack.
+
+Выбор logger и граница ответственности описаны в
+[ADR 008](../adr/008-pino-backend-logging.md); согласованное поведение — в
+workspace-спецификации
+[Structured logging](../../specs/openspec/specs/backend-structured-logging/spec.md).
+Сборщик, срок хранения журналов и alerting не определяются приложением.