docs(observatory): prioritize recorded laboratories and cached review before onboard profiles

docs/OBSERVATORY_REALTIME_PROFILES_EXECPLAN.md

@@ -1,4 +1,111 @@
-# Observatory: четыре этапа создания полного real-time Perception-профиля
+# Observatory: четыре этапа — записанные лаборатории → переносимые профили → борт
+
+## Актуальное решение владельца — 2026-09-02
+
+**Этот раздел заменяет прежний порядок и GO-зависимости плана ниже.** Сначала
+доводим лабораторный продукт на записях, затем экспериментируем с составом
+Docker-профилей, затем переносим выбранный профиль на подходящий бортовой
+компьютер. Сетевые 125 ms, Ethernet, LTE и наличие беспилотника больше не
+являются условиями готовности Observatory. Старый этап 1 и инкременты 1–18
+сохраняются как выполненная инженерная работа; отрицательные realtime-замеры
+не переименовываются в PASS.
+
+Основной путь: **запись → совместимый ещё не рассчитанный профиль → Рассчитать
+→ фактический прогресс → проверенная публикация → сохранённый просмотр**.
+Просмотр, Refresh и выбор записи не запускают модели. Готовые результаты всех
+версий остаются в «Лабораторных доказательствах». Если рассчитаны все текущие
+совместимые профили, выбор пуст/недоступен, кнопки «Рассчитать» нет, «Обновить»
+остаётся. Старое имя LAB не доказывает совпадение версии конфигурации.
+
+### Этап 1 — Идентичность расчёта и переиспользование результата (в работе)
+
+Первый инкремент: portable submit защищён атомарной проверкой существующей
+job identity. Другой ключ запроса не создаёт дубликат active/reconciliation
+или pending/failed-publication job; точный retry идемпотентен, failed compute
+можно повторить. 88 focused backend/queue/Worker-API/publication tests PASS;
+Ruff lint и mypy трёх изменённых source files PASS. Полный frontend/GPU-прогон
+не выполнялся: UI и модели не изменены. Cache projection/селектор/прогресс ещё
+не реализованы, этап не закрыт. Решение: [ADR 0050](adr/0050-recorded-observatory-first.md).
+
+Runtime check 23:15 МСК: canonical8000 перезапущен на новом коде, PID55765,
+health/portable catalog HTTP200,8765 отсутствует. Модельных заданий не создано;
+durable queue содержит10 failed и1 succeeded/not-required, live leases0.
+Обнаружен существовавший ДО перезапуска blocker:50000 claim receipts при
+лимите50000, из них49985 пустых,15 с job. Последний receipt2026-09-01T17:28:39.238Z;
+новые Worker polls продолжают получать503. Каталог всё ещё рекламирует ready,
+что не доказывает работоспособность claim-пути. Следующий инкремент этапа1:
+исправить bounded empty-poll lifecycle и readiness без удаления audit history
+и нарушения идемпотентности старых claim IDs; затем verified-cache projection.
+Не повышать бесконечно лимит и не чистить receipts вслепую.
+
+- Сверить каталог, очередь, публикацию и просмотр для текущих 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 плана (не текущие команды и зависимости)
+
+Ниже сохранены прежние измерения, этапы и решения. Все слова «следующий»,
+«GO», «не открыты» и старые номера этапов в этой истории относятся к состоянию
+до решения выше. Приоритет имеют четыре актуальных этапа выше.
 
 Дата: 2026-09-01; обновлено 2026-09-02 22:35 МСК. **Этап1 закрыт; этап2 продолжается. Инкремент18: существенный транспортный хвост локализован ниже Perception-приложения; full-profile latency не пересчитывалась.** Код `6af4c20`: bounded TLS-record witnesses в CPU-only diagnostic. A/B/A без/с/без свидетелей сохраняет RPC p95 96.093/93.895/95.145ms.424/424 encrypted records и192/192 RPC сопоставлены;288 raw clock exchanges пересчитаны. Из13 post-start tails >50ms восемь приходятся на request transit, пять на response transit; начальный TLS/startup sample не получает выдуманного clock mapping.
 

docs/adr/0049-stream-first-perception-profiles.md

@@ -1,5 +1,10 @@
 # ADR 0049 — Stream-first full perception profiles
 
+> Product scope/order partially superseded on 2026-09-02 by
+> [ADR 0050](0050-recorded-observatory-first.md): recorded calculation and cached
+> review come first. Live-stream contracts and historical measurements below
+> remain intact; remote realtime is no longer the Observatory release gate.
+
 Date: 2026-09-01; updated 2026-09-02 19:42 MSK. Status: stage-1 engineering
 baseline complete; stage-2 has full graph container-network proof plus authenticated
 cross-host grant delivery and bounded clock intervals. Continuous clock readiness is

docs/adr/0050-recorded-observatory-first.md

@@ -0,0 +1,74 @@
+# ADR 0050 — Recorded Observatory first; portable profiles then onboard
+
+Date: 2026-09-02. Decision accepted by the owner; implementation in progress.
+This supersedes ADR 0049's realtime-first product gate and execution order,
+not its live-stream integrity, ownership or safety contracts.
+
+## Decision
+
+The primary operator workflow is a complete calculation of a compatible K1
+recording with a selected immutable profile, followed by publication and cached
+review. Processing may be slower than acquisition. Network latency is evidence,
+not a prerequisite for using the laboratory. After this workflow works, compare
+Docker configurations; later qualify the selected configuration on actual
+onboard hardware. No vehicle or remote-realtime acceptance is claimed now.
+
+Keep the existing source admission, queue, artifact store, publication recovery,
+streaming runtime and common viewer. Do not introduce another per-LAB application.
+One Worker executes one active profile; alternative profiles remain sequential.
+M4.9T5 currently supplies CPU TGS; LAB V1 supplies sequential EoMT/DDRNet, not the
+complete future detector/distance/motion/TGS/policy profile.
+
+## Recorded analysis versus realtime rehearsal
+
+Recorded analysis preserves source timestamps and causal ordering, uses bounded
+backpressure, and accounts for every required scheduled input/result. Its elapsed
+wall time need not match the source clock. Source sensor gaps remain unknown.
+Do not disguise live drop/resync as a complete recorded result. Introducing this
+execution mode requires an explicit versioned contract, not silently weakening
+the existing 1× live freshness, deadline or ownership gates.
+
+Realtime rehearsal remains an independent qualification. Historical network
+canaries retain their original FAIL results and thresholds. Neither cached video
+playback FPS nor end-to-end upload/export time is a Worker compute benchmark.
+Measure preparation, warmup, processing, delivery and publication separately;
+onboard estimates are conditional on matching hardware and effective config.
+
+## Result identity and UI
+
+Only compatible, not-yet-calculated current profile versions belong in the
+calculation selector. Published results of every version remain below as evidence.
+All calculated means no Calculate action, an empty/disabled selector, and Refresh.
+Refresh, source selection and cached review must never start inference.
+
+Reuse requires the exact admitted source fingerprint and immutable definition
+(including model, image, configuration, adapter and result-contract identities).
+An old LAB name, a legacy overlay, or compute success without publication is not
+a matching cache. Missing/corrupt artifacts must not suppress a valid retry.
+Publication failure retries publication, not computation, while the sealed package
+is recoverable. Changed profile versions become new calculations.
+
+## First implementation increment
+
+Portable queue admission now opts into an atomic duplicate-computation guard.
+It uses the existing job identity, not a second cache key ontology, and rejects a
+different request while the identical job is active, requires reconciliation, or
+has a sealed result pending/failed publication. The check and INSERT use one SQLite
+transaction. Exact retries retain the original idempotency semantics. A genuinely
+failed compute can be retried with a new request key. Legacy queue callers retain
+their existing policy; no schema migration or Worker/image change is introduced.
+
+Published-cache verification, catalog projection, selector changes, progress and
+complete recorded-analysis execution are still pending. This increment does not
+mark stage 1 or the full workflow complete. Tests cover concurrent admission,
+durability, changed source/profile, failure retry and HTTP 409 duplicate handling.
+
+## Boundaries
+
+No Synology deployment, hardware actuation, motor integration, new capture,
+silent model substitutions or deletion of recordings/results. A Docker image's
+portability does not promise that a CUDA build runs unchanged on Apple Silicon.
+Physical-live and onboard/vehicle acceptance require the actual target hardware.
+
+The only maintained execution plan is
+[the four-stage ExecPlan](../OBSERVATORY_REALTIME_PROFILES_EXECPLAN.md).