B20: контракт обмена Вектор↔Контур (граница проектов)

Версионированный протокольно-агностичный формат на границе: outbound
(SearchZones/RecommendedRoutes/ResourceTasks/SearchModelMeta) и inbound
(Positions/Tracks/AreasChecked/Observations/FoundEvent). Движок работает
только с форматом, транспорт — адаптеры Контура. От B20 зависят B17 и B18.
Рекоменд.порядок: B14→B15→B20→(B16,B17)→B18.

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
root
2026-08-20 16:53:06 +00:00
parent bef603415f
commit d6e6277d85
+35 -2
View File
@@ -902,6 +902,39 @@ sed -i 's/sar_mchs/vector_mchs/g; s#/root/sar-mchs#/root/vector#g' DEPLOY.md
**Что в репо Вектора:** B17 (приём полевых данных, Контур→Вектор), B18 (перерасчёт + выдача зон, Вектор→Контур), и отдельная задача **«Контракт обмена»** — версионированный формат зон/приоритетов/наблюдений на границе, без зависимости от ATAK/Mesh.
**Что НЕ в репо Вектора:** ATAK-плагины, Meshtastic-firmware/протокол, полевой UI Контура — отдельный проект.
---
## B20 — Контракт обмена Вектор ↔ Контур (граница проектов)
**Тип:** spec / architecture, needs-context. Фундамент развязки (B13-принцип 1): единый версионированный формат данных на границе, без зависимости от ATAK/Meshtastic. От него зависят B17 (ингестия) и B18 (выдача зон) — они реализуются поверх этого контракта.
**Что:** Зафиксировать контракт обмена между Вектором и Контуром — два направления, оба версионированные (`schema_version`), протокольно-агностичные. Транспорт (ATAK CoT / Meshtastic / HTTP / websocket) — дело адаптеров Контура, не Вектора; движок работает только с форматом.
**Вектор → Контур (outbound):**
- `SearchZones[]`: `{zone_id, geom (Polygon GeoJSON), priority (1..N), probability (0..1), reasoning, recommended_resources[]}`
- `RecommendedRoutes[]`: `{route_id, geom (LineString), for_role, estimated_time}`
- `ResourceTasks[]`: `{task_id, target_zone_id, resource_type (team|dog|uav), instruction}`
- `SearchModelMeta`: `{case_id, model_version, generated_at, valid_until, max_distance_km}`
- Событие: «новая версия модели доступна».
**Контур → Вектор (inbound):**
- `Positions` (поток): `{team_id, geom (Point), timestamp, accuracy}`
- `Tracks`: `{team_id, geom (LineString), from, to}`
- `AreasChecked`: `{area_id, geom (Polygon), team_id, checked_at, result (clear|found|partial), coverage_pct}`
- `Observations`: `{obs_id, type (clue|item|place|obstacle|witness), geom, timestamp, team_id, confidence, description, media_ref?}`
- `FoundEvent`: `{case_id, geom, timestamp, condition}`
- Событие: «новое наблюдение» / «зона проверена» (триггерит перерасчёт B18).
**Реализация:** Pydantic-схемы в `backend/schemas/contract.py`, сериализация GeoJSON, `schema_version` на каждом сообщении. Вектор отдаёт outbound через endpoint (SSE / websocket / poll — выбрать) и принимает inbound через endpoints B17. `build_search_model` (B14) отдаёт результат в формате outbound-контракта — в коде движка ни одного упоминания ATAK/Mesh.
**Границы:** НЕ реализовывать ATAK-плагины / Meshtastic-протокол (это Контур, отдельный репо). НЕ менять коэффициенты (B1). НЕ привязывать к конкретному транспортному протоколу — контракт = формат данных, транспорт = адаптер.
**Критерий приёмки:**
- Pydantic-схемы обоих направлений определены, валидируются (round-trip: объект → JSON → объект).
- `build_search_model` (B14) отдаёт результат в формате outbound-контракта (SearchZones + meta); grep по `services/search_engine.py` не находит «ATAK»/«Meshtastic»/«CoT».
- B17 endpoints приёма принимают inbound-контракт и складывают в Field Data таблицы (B15).
- Человекочитаемая документация контракта (markdown или OpenAPI-схема) — для разработчиков Контура.
- Тесты: round-trip сериализация + валидация кейсов (clue / obstacle / area_checked / zone).
---
# Сводка
@@ -911,7 +944,7 @@ sed -i 's/sar_mchs/vector_mchs/g; s#/root/sar-mchs#/root/vector#g' DEPLOY.md
| Atomic (backend) | A1–A9 | локальной LLM |
| Atomic (frontend) | A10–A16 | локальной LLM |
| Needs-context | B1–B12 | сильной модели / человеку |
| Архитектура / рефакторинг | B13 (каркас), B14 (SearchEngine), B15 (слои данных), B16 (GIS/PostGIS), B17 (Field Data), B18 (итеративность + queue) | сильной модели / человеку |
| Архитектура / рефакторинг | B13 (каркас), B14 (SearchEngine), B15 (слои данных), B16 (GIS/PostGIS), B17 (Field Data), B18 (итеративность + queue), B20 (контракт Вектор↔Контур) | сильной модели / человеку |
| Отдельный проект | B19 «Контур» (ATAK+Meshtastic, полевая система) | отдельный репо/спецификация |
**Рекомендуемый порядок:** сначала B14 (чистый движок, поведение-сохраняющий — фундамент), затем B15 (слои данных), затем B16 (GIS) и B17 (Field Data) можно параллельно, затем B18 (итеративность + queue). B12 (ISRID) разблокируется внешне (правовой статус) и подключается как источник априорных к B18. B19 «Контур» — отдельный проект (свой репо); со стороны Вектора: B17+B18+контракт обмена. Коэффициенты (B1) — под ревью человека на каждом шаге.
**Рекомендуемый порядок:** B14 (чистый движок) → B15 (слои данных) → **B20 (контракт Вектор↔Контур)** → B16 (GIS) и B17 (Field Data) параллельно → B18 (итеративность + queue). B12 (ISRID) разблокируется внешне (правовой статус) и подключается как источник априорных к B18. B19 «Контур» — отдельный проект (свой репо); со стороны Вектора: B17+B18+B20. Коэффициенты (B1) — под ревью человека на каждом шаге.