docs(observatory): refresh four-stage recorded-first roadmap

This commit is contained in:
DCCONSTRUCTIONS
2026-09-03 10:35:48 +03:00
parent 44afadb021
commit 4e0565eb4b
2 changed files with 233 additions and 81 deletions
+225 -81
View File
@@ -1,26 +1,233 @@
# Observatory: четыре этапа — записанные лаборатории → переносимые профили → борт # Observatory: четыре этапа — записанные лаборатории → переносимые профили → борт
## Актуальное решение владельца — 2026-09-02 ## Актуальный маршрут — 2026-09-03
**Этот раздел заменяет прежний порядок и GO-зависимости плана ниже.** Сначала Сверено с кодом `e436fb5`, evidence до `44afadb` и последними решениями владельца.
доводим лабораторный продукт на записях, затем экспериментируем с составом Эта актуализация меняет только документы: новые расчёты, сборки, измерения Worker
Docker-профилей, затем переносим выбранный профиль на подходящий бортовой и изменения сервисов не выполнялись. Разделы до журнала инкрементов — текущий
компьютер. Сетевые 125 ms, Ethernet, LTE и наличие беспилотника больше не маршрут; исторические «следующий шаг» и «этап открыт/закрыт» ниже не команды.
являются условиями готовности Observatory. Старый этап 1 и инкременты 1–18
сохраняются как выполненная инженерная работа; отрицательные realtime-замеры
не переименовываются в PASS.
Основной путь: **запись → совместимый ещё не рассчитанный профиль → Рассчитать ### Цель и результат
→ фактический прогресс → проверенная публикация → сохранённый просмотр**.
Просмотр, Refresh и выбор записи не запускают модели. Готовые результаты всех
версий остаются в «Лабораторных доказательствах». Если рассчитаны все текущие
совместимые профили, выбор пуст/недоступен, кнопки «Рассчитать» нет, «Обновить»
остаётся. Старое имя LAB не доказывает совпадение версии конфигурации.
Уточнение владельца 2026-09-03: никаких кнопок/плашек «Расчёт завершён»,
«Результат опубликован» и аналогичных подтверждений. Готовность видна по
результату с маркером профиля внизу; в выборе остаются только нерассчитанные.
### Этап 1 — Идентичность расчёта и переиспользование результата (в работе) Оператор записывает маршруты K1, один раз рассчитывает совместимую запись
выбранным профилем и затем изучает сохранённый результат без повторного inference.
Один профиль применяется к разным записям, разные профили сравниваются на одной.
Удачный полный профиль впоследствии переносится на фактический бортовой компьютер.
Лаборатория допускает расчёт медленнее записи. Требуются полнота предусмотренного
профилем анализа, качество, воспроизводимость и честные измерения. Remote realtime
PASS через Wi-Fi/LTE не является условием готовности лабораторий. Потоковые
контракты, bounded очереди, scheduler, ownership/recovery и телеметрия сохраняются.
### CURRENT: что есть и чего ещё нет
- **Реализовано и локально проверено:** source/profile admission, durable queue,
защита от дубликатов, восстановленный claim/v3, точный опубликованный кэш,
выбор только совместимых нерассчитанных portable profiles и общие viewer contracts.
- **UI:** готовность видна только по результату внизу. Все текущие профили
рассчитаны → выбор пуст, «Рассчитать» нет, «Обновить» остаётся. Плашек завершения
нет; во время работы пока только индикатор ожидания. Лимит первых 6 карточек снят,
но пагинация сотен записей ещё не доказана.
- **Последняя приёмка, не новый замер:** 720 frontend tests, 52 focused queue/API
tests, typecheck/build и browser QA PASS. В очереди тогда 11 jobs: 10 failed и
1 succeeded/not-required; точного нового published cache hit не было.
Положительные all-cached/reuse сценарии пока доказаны synthetic tests.
- **Текущие составы:** M4.9T5 — CPU TGS; LAB V1 — последовательные EoMT и DDRNet.
Ни один не равен полному будущему AI-профилю рига. Архивные overlays в одном
viewer не доказывают, что один Docker вычислил все слои.
- **Есть инженерный прототип полного графа:** DDRNet/RF-DETR/geometry/distance/
motion/TGS/costmap/policy-shadow и короткие потоковые proofs. Не пишем заново.
Самостоятельный продуктовый образ и полный recorded-run этого состава не приняты.
- **Не закрыто:** реальные счётчики прогресса, полный recorded-analysis текущими
профилями, publish→cache→view после перезапуска на реальных данных, полный поиск/
пагинация каталога, standalone и фактический перенос на борт.
Источники: [ADR 0050](adr/0050-recorded-observatory-first.md),
[cache/UI evidence](../experiments/perception/OBSERVATORY_PUBLISHED_CACHE_2026-09-03.md),
[claim/v3](../experiments/perception/OBSERVATORY_RECORDED_CLAIM_REPAIR_2026-09-02.md).
Desktop final-status — операторская сводка и история; подробный маршрут ведётся
только здесь. Из CODEX_V5 взяты разделение CURRENT/TARGET, критерии готовности и
сохранение выполненной работы, не неподтверждённые сведения о runtime.
## Границы исполнения
- Один Worker 006/RTX 4090 — один активный профиль; альтернативы и тяжёлые проверки
последовательны. DDRNet и RF-DETR допустимы внутри одного полного профиля с
последовательным GPU inference. EoMT сохраняется отдельно; существующий
сравнительный LAB V1 не превращается в параллельный запуск двух segmenters.
- Только Mission Core 8000 и Worker 006, без Synology/deploy-canon21, новых
LAB-микроприложений и изменений чужих сервисов. На Mac 18GB — resource gate,
последовательные проверки, без нагрузочных тестов и остановки чужих приложений.
- Записи, история, артефакты и отрицательные замеры сохраняются. Не выдумывать
capture attestation RAVNOVES01; новая конфигурация/семантика получает новую
версию, старые результаты сохраняют свою идентичность.
- Полнота recorded-analysis не ослабляет live freshness/ownership. Временные
сетевые/телеметрические сбои восстанавливаются по существующему контракту,
без бесконтрольных рестартов моделей и второго владельца Worker.
- Пока observation-only/policy-shadow. Моторы, автономная навигация и controller/
safety acceptance не включаются скрыто. Борт и более мощная GPU не блокируют этапы 1–3.
## Этап 1 — Основа, идентичность и выбор профиля
**Состояние:** основа реализована и локально проверена. Это не утверждение,
что весь пользовательский цикл уже принят: сквозная приёмка явно в этапе 2.
Повторно строить queue/cache/selector не требуется.
**Результат:** exact source snapshot + immutable profile + проверенный пакет
определяют reuse. Повторный клик не создаёт конкурирующий расчёт, новая версия
не скрывается старым названием LAB, завершение не дублируется кнопкой/плашкой.
**Доказательства:** queue/cache/decoder tests, first-render selection fences,
normal/expanded UI; последний код `e436fb5` и отчёты выше. Остаток — исправлять
только дефекты, обнаруженные сквозным циклом 2, а не повторять выполненный ремонт.
## Этап 2 — Полный цикл записанной лаборатории — следующий активный этап
**Цель:** полный расчёт записи, фактический прогресс, пригодный для просмотра
опубликованный результат и повторное открытие после перезапуска без inference.
**2A. Полный анализ и прогресс.** Сверить текущие executor inputs/outputs с
наработанным runtime. Явно оформить версионированный `recorded-analysis` отдельно
от `realtime-rehearsal`; сначала малые контрактные fixtures, не долгий GPU-run.
- Сохранить source timestamps и causal ordering. Медленный Worker притормаживает
подачу, а не выбрасывает обязательные кадры ради 1×. Учитывается каждый вход/
выход по расписанию профиля; stride, sensor gaps и overload drops различаются.
- Ограничить чтение, decode, буферы, транспорт и запись outputs. Полное
предварительное накопление/пересылка исходной сессии не становится постоянным
условием старта. Sealing выходного пакета после EOF — не input barrier.
- Передать реальные счётчики Worker через backend в общий UI: обработанные
единицы, доступный знаменатель, текущая фаза. Не выдумывать проценты/ETA;
различать попытки. Хранить ограниченный актуальный снимок, не бесконечный
journal на каждый кадр. После публикации прогресс исчезает, остаётся результат.
- Различать preparation, warmup, compute, transport и publication. При исправимой
ошибке публикации повторять публикацию сохранённого пакета, не inference.
**2B. Первый вертикальный proof: M4.9T5 × RAVNOVES004TREE.** Пройти полный путь
через обычный UI и Worker: вход → расчёт → реальный прогресс → sealed package →
публикация → маркер конфигурации внизу → общий viewer → повторное открытие.
Из выбора исчезает именно рассчитанная версия. Проверить полноту TGS-выходов и
timeline. Это приёмка CPU TGS, не полного detector/segmentation профиля.
Историческая M4.9 projection без review binding не заменяет этот proof.
**2C. LAB V1 и другая запись.** Выполнить LAB V1 × 004TREE, затем оба профиля
× RAVNOVES00, строго последовательно. Медленная EoMT не возвращает нас к гонке
за сетевым FPS. Не менять незаметно состав, cadence или разрешение ради PASS.
RAVNOVES01 — отрицательный случай до подтверждённой аттестации.
**2D. Повторное использование, сбои и большой каталог.**
- Refresh, повторный вход и перезапуск открывают тот же результат без новой job.
Все текущие профили рассчитаны → выбор пуст, «Рассчитать» нет; новая версия → новый расчёт,
старая остаётся ниже. Проверить transient disconnect, compute failure,
publication retry, missing/corrupt artifacts и отсутствие дубликатов.
- Исторические результаты получают допуск к review только при достаточном
evidence, без подделки provenance. Если binding отсутствует — исправить
проверяемую проекцию либо выполнить новый расчёт, не объявлять legacy новым.
- Довести постраничный поиск записей и результатов. Нельзя спрятать профиль
из-за cache hit, соответствующий результат которого нельзя найти/открыть
из-за окна каталога. Сотни metadata entries проверяются функциональными
fixtures, не нагрузкой на Mac и не загрузкой всех видео в RAM.
**Приёмка:** матрица 2 профиля × 2 совместимые записи, полные обязательные выходы,
честный прогресс, published package, сохранённый просмотр без compute после
перезапуска, проверенные recovery/negative cases и сохранность истории.
Успешный первый M4.9 run закрывает 2B, не автоматически весь этап 2.
Зависимости: основа 1, текущие записи и Worker; не новый полный профиль или борт.
## Этап 3 — Самостоятельные Docker-профили и лабораторные эксперименты
**Цель:** воспроизводимый полный профиль для разных маршрутов и честное сравнение
конфигураций через уже принятый лабораторный цикл 2.
1. Включить готовый граф/runtime в самостоятельный профиль: DDRNet + RF-DETR +
LiDAR association/distance + static obstacles + temporal/motion + TGS/costmap +
policy-shadow. Не подмешивать обязательные выходы из чужих старых overlays.
2. Веса, модельные runtime, конфигурация и graph входят в переносимую поставку;
холодный старт без developer checkout/скрытых model caches. Записи, результаты
и секреты внешние; backend/broker/БД не внутри perception-контейнера.
Понятные profile/image имена с `ndc-`, версией и digest, без слепых переименований.
3. Для сельского прототипа оставить coarse hard_surface и общий static-obstacle.
Людей/животных/динамику/расстояния проверять на выбранных сценах; не обещать
качество по FPS. Второй segmenter, городской автопилот и обязательная новая
разметка не нужны. EoMT — отдельная сохраняемая альтернатива.
4. До каждого последовательного эксперимента фиксировать effective config и
Worker/GPU baseline; измерять отдельно preparation/warmup, compute, queues,
transport, publication и качество. Оптимизировать подтверждённые узкие места,
не возвращаться к бесконечной погоне за Wi-Fi latency.
**Приёмка:** cold start переносимого пакета, весь заявленный граф в одном run,
воспроизводимые результаты на нескольких маршрутах, сравнение конфигураций и
явные слабые места. Перегрузка GPU — допустимый исход эксперимента; безопасные
пределы памяти/очередей остаются. Worker-only throughput и full-graph latency —
условный baseline на этом железе, не обещание onboard FPS. Viewer FPS и вычитание
несвязанных p95 не заменяют измерение. Наработки старого плана не переписываются.
## Этап 4 — Отбор кандидата и перенос на фактический борт
**Цель:** выбранная конфигурация воспроизводится на целевом компьютере, её
границы известны до подключения автономного управления.
**Работа/доказательства:** зафиксировать образ/config, оборудование, калибровки,
матрицу качества/нагрузки и ограничения. После появления борта проверить местный
вход, те же timestamps/выходные контракты, весь граф, latency, ресурсы и recovery.
CUDA-образ не объявлять автоматически переносимым на Apple Silicon: другая
архитектура требует подходящей сборки и повторной квалификации.
**Закрытие:** пакет кандидата — готовность лабораторной части; реальный перенос
pending до испытания фактического оборудования. Flight controller/ArduRover,
watchdog, stop/slow при пропаже данных, моторы и автономное прохождение —
отдельный согласованный допуск. Красивый replay его не заменяет.
## Progress / точка продолжения
- [x] 2026-09-03 — этап 1: queue/cache/identity/selector реализованы и локально проверены.
- [x] 2026-09-03 — история сохранена, completed-status UI удалён.
- [ ] Этап 2A — полный recorded-analysis и счётчики; сейчас только activity indicator.
- [ ] Этап 2B2D — новый M4.9 full run, затем LAB V1/вторая запись, cache/recovery/каталог.
- [ ] Этап 3 — самостоятельный полный профиль и сравнение конфигураций.
- [ ] Этап 4 — кандидат, затем фактическая бортовая квалификация.
- [x] 2026-09-03 — план актуализирован; в этом ходе следующие пункты не исполнялись.
**Непосредственно следующий инкремент — 2A:** сверить пути executor/progress,
оформить минимальный режим полного анализа и настоящие счётчики, проверить на
малых fixtures. Затем 2B — M4.9T5 × 004TREE до сохранённого просмотра.
Не начинать снова с claim/v3, memory repair, селектора или сетевого canary.
## Карта продолжения, проверка и восстановление
- `src/k1link/observatory/recorded_jobs.py`, `worker_agent.py`,
`installed_lab_package_runner.py` — job, ownership и исполнение.
- `src/k1link/observatory/m49_portable_executor.py`,
`portable_lab_v1_executor.py`, `m49_portable_source.py` — текущие adapters.
- `portable_result_publisher.py`, `portable_publication_reconciler.py`,
`portable_result_cache.py` в том же каталоге — publish/recovery/cache.
- `apps/control-station/src/core/observatory/` и
`apps/control-station/src/workspaces/observatory/ObservatoryWorkspace.tsx`
проекции и общий экран, не новая модельная orchestration.
- Runtime/graph paths и численные proofs — в прежнем плане и связанных отчётах
ниже. Перед конкретным изменением сверять владельца модуля.
Каждый инкремент проверяется по своему результату: contract tests, необходимый
Worker proof, затем UI/evidence. UI-изменения следуют product-ui canon; новые
visual entities требуют отдельного решения. Проверка идентичности не доказывает
качество. При сбое сохранять последнее проверенное состояние, не очищать очередь
и не повторять закрытые этапы; новую hardware/authority потребность выделять явно.
## Решения и расхождения документации
- 2026-09-02, владелец: recorded-first вместо сетевого realtime-first; старые
FAIL сохраняются, лаборатории не зависят от LTE/борта.
- 2026-09-03, владелец: результат внизу вместо completion button/status — реализовано.
- 2026-09-03, актуализация: этап 1 — реализованная основа, сквозной proof явно
в этапе 2. Это уточнение границы приёмки, не приписывание успешного end-to-end run.
- Desktop17/20, утверждение об отсутствии online prototype и безусловный1×
устарели. Исправлены по решениям владельца; прошлые цифры/попытки сохранены.
## Журнал recorded-first инкрементов — история, не текущие TODO
Промежуточные «ещё не реализовано», «следующий шаг» и stopping points ниже
относятся к соответствующей итерации; текущий статус и маршрут — выше.
Первый инкремент: portable submit защищён атомарной проверкой существующей Первый инкремент: portable submit защищён атомарной проверкой существующей
job identity. Другой ключ запроса не создаёт дубликат active/reconciliation job identity. Другой ключ запроса не создаёт дубликат active/reconciliation
@@ -119,69 +326,6 @@ Ruff/mypy и production build PASS. Подробная финальная runtim
операторских данных остаются следующим acceptance этапа2, а не объявляются операторских данных остаются следующим acceptance этапа2, а не объявляются
закрытыми этой правкой интерфейса. закрытыми этой правкой интерфейса.
- Сверить каталог, очередь, публикацию и просмотр для текущих M4.9T5 и LAB V1.
- Связать готовность с точной исходной записью и immutable RunDefinition,
включающей image/model/config/adapter/result-contract identities.
- Подавлять повторную постановку активного идентичного расчёта на backend;
опубликованный кэш признавать только при проверенной привязке и доступных
артефактах. Failed/partial/unpublished не считать готовым результатом.
- Отделить архивные результаты от исполняемых профилей и не прятать новую
версию профиля из-за старого результата с похожим названием.
Выход: контрактные тесты для другой записи/версии, повторного клика, гонки,
ошибки публикации и отсутствующих артефактов; актуальные документы. Это ещё
не полный пользовательский acceptance.
### Этап 2 — Полный пользовательский цикл записанной лаборатории
- Единый селектор только совместимых нерассчитанных профилей; все доступные
результаты ниже, без скрытого ограничения первыми шестью карточками.
- Очередь, реальные счётчики/этапы прогресса, ошибки, повтор публикации без
inference, автоматическое обновление после публикации.
- Полный расчёт с сохранением результатов и исходной временной шкалы;
скорость расчёта может быть ниже скорости записи. Ограниченные очереди и
backpressure вместо накопления всей записи в RAM. Разделить режим полноты
записанного анализа и строгий realtime-rehearsal: не отключать freshness
и drop-политику live глобально и не терять кадры ради wall-clock темпа
в режиме полного анализа.
- Последовательно проверить текущие два профиля на совместимых записях:
публикация, перезапуск приложения, повторный просмотр без модели/GPU,
отсутствие дубликатов. Не объявлять LAB V1 полным detector/distance/TGS
профилем: сейчас это последовательные EoMT и DDRNet; M4.9T5 — CPU TGS.
Выход: настоящий путь через canonical8000 и Worker, полный сохранённый
результат и воспроизводимый просмотр. До такого proof этап открыт.
### Этап 3 — Эксперименты с переносимыми Docker-конфигурациями
- Переиспользовать наработанный streaming runtime и общий контроль исполнения.
В первую очередь новый DDRNet + RF-DETR + LiDAR/distance + motion +
TGS/costmap + policy-shadow, без зависимости от чужих архивных overlays.
- Один Worker006/4090 — один активный профиль. EoMT сохраняется; альтернативы
не выполняются параллельно. Понятные profile/image имена с `ndc-` и digest.
- Измерять отдельно подготовку, прогрев, Worker compute/full-graph latency,
доставку, публикацию и wall time всего задания. Перегрузка — результат
эксперимента, а не повод запретить лабораторный расчёт.
- Условный прогноз onboard FPS относится только к измеренным железу, образу,
настройкам и составу; не выводится из viewer FPS или времени скачивания.
Выход: сравнимые результаты конфигураций на нескольких записях, известные
ошибки, воспроизводимые образы; не обязательный remote realtime PASS.
### Этап 4 — Отбор профиля и проверка переноса на борт
- Выбрать удачный immutable образ/config по лабораторной матрице качества и
производительности; исключить checkout и скрытые model caches из зависимостей.
- Проверить тот же образ и входной контракт на фактическом бортовом компьютере
после его появления. Другая архитектура CPU/GPU может потребовать отдельной
сборки и новой квалификации; Docker не обещает NVIDIA→Apple Silicon перенос
без изменений.
- Physical-live, контроллеры/моторы, аварийная остановка и автономная навигация
имеют отдельную приёмку. Пока только observation-only/policy-shadow.
Выход сейчас: пакет кандидата, матрица evidence и явные ограничения; реальный
перенос остаётся pending до появления оборудования, не блокируя этапы 1–3.
## История прежнего realtime-first плана (не текущие команды и зависимости) ## История прежнего realtime-first плана (не текущие команды и зависимости)
Ниже сохранены прежние измерения, этапы и решения. Все слова «следующий», Ниже сохранены прежние измерения, этапы и решения. Все слова «следующий»,
@@ -48,6 +48,14 @@ a matching cache. Missing/corrupt artifacts must not suppress a valid retry.
Publication failure retries publication, not computation, while the sealed package Publication failure retries publication, not computation, while the sealed package
is recoverable. Changed profile versions become new calculations. is recoverable. Changed profile versions become new calculations.
## Implementation checkpoints
The checkpoints below are chronological evidence, not a current TODO list.
As of 2026-09-03, the queue/claim/cache/selector foundation is implemented and
locally checked. Full recorded-analysis, measured progress and end-to-end
published review on real recordings remain unaccepted; the current four-stage
route and next increment are maintained only in the linked ExecPlan.
## First implementation increment ## First implementation increment
Portable queue admission now opts into an atomic duplicate-computation guard. Portable queue admission now opts into an atomic duplicate-computation guard.