41 lines
2.2 KiB
Markdown
41 lines
2.2 KiB
Markdown
---
|
||
work_item: ORCH-100
|
||
stage: architecture
|
||
author_agent: architect
|
||
status: proposed
|
||
created_at: 2026-06-10
|
||
model_used: claude-opus-4-8
|
||
---
|
||
|
||
# 08 — Требования к данным: ORCH-100 — FND/F1b: sidecar-watchdog
|
||
|
||
Work Item: **ORCH-100** · Repo: **orchestrator** · Стадия: architecture
|
||
|
||
> When-applicable. Создан для аудитопригодности: фиксирует, что схема БД **не меняется** — это
|
||
> архитектурное утверждение (sidecar вне процесса орка, без своей БД), а не пропуск.
|
||
|
||
## Изменения схемы БД орка
|
||
|
||
**N/A.** Sidecar **не пишет** в БД орка (NFR-4: строго read-only к наблюдаемому — нет
|
||
`INSERT/UPDATE/DELETE/CREATE/ALTER`) и **не читает** её напрямую: всё орк-сырьё идёт через
|
||
`GET /metrics` (F1a, adr-0030). `tasks`/`jobs`/`agent_runs`/`STAGE_TRANSITIONS`/`QG_CHECKS` —
|
||
не тронуты.
|
||
|
||
## Собственное хранилище sidecar
|
||
|
||
**Нет (по решению C-3 / ADR-001 D4).** Состояние порогов (`AlertState`: `alerting`/`last_alert_at`
|
||
per signal_key) — **in-memory best-effort** в процессе демона: ни таблицы, ни файла, ни миграции.
|
||
Рестарт sidecar сбрасывает карту состояний → ещё стоящая проблема корректно повторно алертится один
|
||
раз (ранний сигнал, не SLA) — 1:1 семантика `disk_watchdog.PathAlertState` (ORCH-063).
|
||
|
||
## Журнал уроков (F2)
|
||
|
||
**Вне объёма.** Долговременное хранение инцидентов/уроков (потенциально БД орка) — отдельная задача
|
||
домена F2; F1b ничего не персистит (BRD §«Вне объёма»).
|
||
|
||
## Вывод
|
||
|
||
Изменений данных/схемы нет. Контракт данных F1b — **потребление** версионированного JSON `/metrics`
|
||
(adr-0030) + эфемерное in-memory состояние порогов. Откат не оставляет следов в БД.
|
||
</content>
|