Files
wiki/tasks/flightradar24/docs/DEV_AGENT_HANDOFF.md
2026-04-19 00:20:01 +03:00

130 lines
4.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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: 1012 GB
- SSD: 80100 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-агент успешно передал работу, если после его первого прохода:
- понятно, какие сервисы и как поднимаются
- понятно, где жить данным
- понятно, как восстанавливать отставание
- понятно, что осталось уточнить перед запуском в прод