# Dev-agent handoff: FR24 / noisemap RTL-SDR ingest

## 1. Контекст
Проект переходит от FR24-only прототипа к локальному ADS-B ingest-контуру на RTL-SDR.

Нужно построить внутри одной VM:
- Docker Compose стек
- PostgreSQL + PostGIS
- capture
- preprocess
- API / viewer
- мониторинг по необходимости

## 2. Что должно быть сделано
### Основной объём работ
- описать и реализовать Docker Compose стек
- подготовить контейнер PostgreSQL/PostGIS
- реализовать capture-контур приёма ADS-B
- реализовать preprocess-контур нормализации и recovery
- реализовать API для карты / noisemap
- подготовить healthchecks
- подготовить backup/restore процедуру
- зафиксировать схему БД и индексы

### Что важно не забыть
- raw retention = 3 дня
- live + recovery + overlap
- одна VM
- один PostgreSQL
- сырьё и core-данные разделены логически
- код и схема БД должны быть компактными, без лишних слоёв

## 3. Ограничения
### Железо
- CPU: до 6 vCPU
- RAM: 10–12 GB
- SSD: 80–100 GB

### Архитектурные ограничения
- без лишних VM
- без брокера очередей, если он не нужен по факту
- без тяжёлой нормализации
- без хранения сырья дольше согласованного retention без причины

### Что не трогать без отдельного решения
- PVE-хост
- текущий FR24/noisemap прототип как работающий артефакт
- секреты и ключи

## 4. Источники правды
Dev-агент должен читать:
- `tasks/flightradar24/PROJECT.md`
- `tasks/flightradar24/docs/ARCHITECTURE.md`
- `tasks/flightradar24/docs/RTL-SDR_TZ.md`
- `tasks/flightradar24/docs/VM_SETUP.md`
- `tasks/flightradar24/prototype/docs/ARCHITECTURE.md`
- `tasks/flightradar24/prototype/docs/NOISE_MODEL.md`

## 5. Нужный результат от Dev-агента
### Deliverables
- `docker-compose.yml`
- Dockerfile / образа для сервисов
- SQL schema / migrations
- capture service
- preprocess service
- API service
- healthcheck endpoints
- backup/restore notes
- runtime README
- test report with commands and outputs

### Acceptance criteria
- VM + compose stack стартуют без ручной магии
- RTL-SDR доступен контейнеру capture
- raw-данные попадают в PostgreSQL
- preprocess умеет добирать пропуски после сбоя
- tracks / flights / points доступны для карты
- PostGIS используется для геоданных
- compose можно перезапустить без потери консистентности
- smoke / integration / recovery tests documented and passed
- all blockers for final hardware verification explicitly listed

## 6. Предпочтительный порядок реализации
1. Схема БД
2. Compose scaffold
3. PostgreSQL/PostGIS
4. capture
5. preprocess
6. API
7. recovery / overlap
8. backup / monitoring
9. документация

## 7. Рекомендуемый формат задания Dev-агенту
Использовать один запуск с явным scope.

```text
Прочитай:
- tasks/flightradar24/PROJECT.md
- tasks/flightradar24/docs/ARCHITECTURE.md
- tasks/flightradar24/docs/RTL-SDR_TZ.md
- tasks/flightradar24/docs/VM_SETUP.md

Сделай:
1) Docker Compose стек для RTL-SDR ingest-контура
2) PostgreSQL + PostGIS
3) capture/preprocess/API сервисы
4) healthchecks
5) backup/restore notes
6) краткий отчёт по рискам и что ещё нужно от Славы

Ограничения:
- одна VM
- raw retention 3 дня
- live + recovery + overlap
- компактная схема, без лишней сложности

Верни:
- список созданных файлов
- список ключевых решений
- список открытых вопросов
```

## 8. Что считать успехом
Dev-агент успешно передал работу, если после его первого прохода:
- понятно, какие сервисы и как поднимаются
- понятно, где жить данным
- понятно, как восстанавливать отставание
- понятно, что осталось уточнить перед запуском в прод