auto-sync: 2026-04-19 00:10:01

memory/ontology/graph.jsonl

@@ -143,3 +143,4 @@
 {"op": "update", "id": "proj_snowbike_rag", "properties": {"folder": "tasks/snowbike-rag/", "doc_path": "tasks/snowbike-rag/PROJECT.md"}, "timestamp": "2026-04-18T15:03:14.572807+00:00"}
 {"op": "update", "id": "task_snowbike_kb_viewer", "properties": {"folder": "tasks/snowbike-rag/TASKS/active/kb-viewer/", "doc_path": "tasks/snowbike-rag/TASKS/active/kb-viewer/TASK.md"}, "timestamp": "2026-04-18T15:03:14.572807+00:00"}
 {"op": "create", "entity": {"id": "task_snowbike_rag_project_setup", "type": "Task", "properties": {"title": "Оформить Snowbike RAG как проект", "status": "active", "project": "proj_snowbike_rag", "folder": "tasks/snowbike-rag/TASKS/active/project-setup/", "doc_path": "tasks/snowbike-rag/TASKS/active/project-setup/TASK.md"}, "created": "2026-04-18T15:03:14.572807+00:00"}, "timestamp": "2026-04-18T15:03:14.572807+00:00"}
+{"op": "create", "entity": {"id": "task_fr24_rtl_sdr_iteration_2", "type": "Task", "properties": {"title": "FR24 RTL-SDR ТЗ: вторая итерация", "status": "open", "priority": "high", "project": "proj_noisemap", "description": "Дооформить вторую итерацию ТЗ для RTL-SDR контура: мониторинг, healthchecks, ротация логов, индексы/партиционирование, dedup для overlap, backup/restore, уведомления, контракт ingest↔UI."}, "created": "2026-04-18T21:03:00Z"}, "timestamp": "2026-04-18T21:03:00Z"}

tasks/flightradar24/docs/RTL-SDR_TZ.md

@@ -194,8 +194,8 @@
 - какие индексы и партиционирование делать на старте
 - где именно будет жить API noisemap после переноса
 
-## 12. Анализ: ничего ли не упущено
-Что ещё важно добавить в следующую итерацию ТЗ:
+## 12. Итерация 2 — обязательный список улучшений
+Следующая итерация ТЗ должна включать:
 - мониторинг отвалившегося RTL-SDR и автоперезапуск capture
 - healthcheck контейнеров и БД
 - политика ротации логов и объёма диска
@@ -204,7 +204,16 @@
 - экспорт/импорт исторических данных при миграции
 - резервное копирование PostgreSQL и восстановление
 - уведомления о деградации приёма или заполнении диска
-- если FR24 проект остаётся отдельным приложением, определить контракт между ingest-слоем и noisemap UI
+- контракт между ingest-слоем и noisemap UI, если они остаются раздельными
+
+## 13. Анализ: ничего ли не упущено
+Дополнительно стоит проверить перед реализацией:
+- нужен ли отдельный UI мониторинга
+- где живёт API после переноса
+- как именно партиционируются `raw_packets` и `track_points`
+- нужен ли отдельный архив после 3 дней
+- какую политику дедупликации выбрать для overlap на границах
+- как восстанавливать БД после полного падения VM
 
 ---
 Подготовлено на основе текущей архитектуры FR24/noisemap и согласованных ограничений VM.