47 lines
1.6 KiB
Markdown
47 lines
1.6 KiB
Markdown
# ADR 002: Storage And Persistence Model
|
|
|
|
## Status
|
|
|
|
Accepted
|
|
|
|
## Context
|
|
|
|
Проект не должен начинаться с чисто временного `in-memory` мышления, иначе потом придется переделывать:
|
|
|
|
- task lifecycle;
|
|
- event log;
|
|
- confirmations;
|
|
- worker session tracking;
|
|
- replay и audit.
|
|
|
|
## Decision
|
|
|
|
Хранилище проектируется как persistent-first:
|
|
|
|
- production target: PostgreSQL;
|
|
- local development fallback: SQLite без Docker;
|
|
- repository interfaces определяются в application/domain boundary;
|
|
- materialized current state хранится отдельно от append-only event log;
|
|
- критические переходы состояний должны логироваться как события.
|
|
|
|
## Data Model Principles
|
|
|
|
1. `tasks`, `task_nodes`, `confirmations`, `worker_sessions` хранят текущее состояние.
|
|
2. `task_events` хранит audit trail и feed для replay/debugging.
|
|
3. Вызовы моделей, MCP и worker сохраняются как отдельные invocation records.
|
|
4. Артефакты хранят metadata в БД, а payload может лежать во внешнем файловом хранилище.
|
|
|
|
## Consequences
|
|
|
|
Плюсы:
|
|
|
|
- можно строить UI progress и audit без догадок;
|
|
- проще реализовать replay/resume;
|
|
- нет боли миграции с “простых dict” на реальную БД.
|
|
|
|
Минусы:
|
|
|
|
- немного более сложный старт;
|
|
- нужно заранее аккуратно продумать схему.
|
|
|