Complete VIDEO-001 through VIDEO-004 software video studies

docs/video/VIDEO_004.md

@@ -0,0 +1,310 @@
+# VIDEO-004: скорость программного приёмника и защита видео от потери пакетов
+
+16 сентября 2026 года. Worktree `SDR_Rover_Video`, ветка `video-development`,
+исходный HEAD `af7c05f`. Все опыты программные: `RF TX = 0`, SDR не открывался.
+Файлы VIDEO-001/002/003 и производственный BPSK не заменялись. Коммит и push
+не выполнялись.
+
+## Вывод и граница опыта
+
+`VIDEO-004 STATUS = PARTIAL`. Прогретый доступный программный путь выполнил
+порог скорости: фактор реального времени **0,130** на исходном 32-пакетном
+сигнале и **0,131** на 40-пакетном пути с внешним FEC. Порог `≤0,67` и
+предпочтительный `≤0,50` пройдены на этом ПК. Восстановлены четыре стёртых
+пакета и четыре видеокадра побайтно. Существующий H.264 SHORT_GOP проверен
+отдельной моделью доставки.
+
+Это **AVAILABLE SOFTWARE PATH REALTIME FACTOR**, а не скорость полного SDR RX.
+В потоковом замере сигнал уже дан с известными символьными отсчётами.
+`TIMING RECOVERY = NOT_IMPLEMENTED_IN_THIS_BENCHMARK` и
+`CARRIER TRACKING FROM RAW IQ = NOT_IMPLEMENTED_IN_THIS_BENCHMARK`.
+RRC-проверка с известными тактами существует отдельно. Её время не включено
+в число 0,130. Модель не оценивает операторское качество и не доказывает
+устойчивость через эфир.
+
+При пяти затравках и двух шестисекундных окнах NORMAL 640×360/10 лучший
+проверенный для 1–5% потерь вариант `QPSK 500 / inner FEC 2/3 / outer 8+1`
+с дополнительным проверочным пакетом для блока опорного кадра показал
+**591/600 кадров при 1%** и **498/600 при 5%**. Потеря 102 кадров из 600
+при 5% вместе с малым запасом пропускной способности не позволяет объявить
+этот режим надёжно поддерживаемым. `NORMAL SUPPORTED IN SOFTWARE MODEL = NO`
+для всего диапазона 1–5% с принятым в VIDEO-003 запасом 20% к пику.
+Это не отрицание отдельных
+успешных прогонов.
+
+## Скорость: одинаковый вход до и после
+
+Канонический вход содержит 32 полных PHY-пакета QPSK 500 ксимв/с, inner FEC
+2/3, 9 dB `Eb/N0`, сдвиг несущей 73 Гц и 42 переходных символа на пакет.
+Затравка `20260916`; файл `data/processed/video004/canonical_symbols.npy`
+проверяется по SHA-256 из `canonical_manifest.json`. Приёмник узнаёт размер
+пакета из принятого PHY-заголовка. Эталонные SHA передаются только проверке
+после CRC. Длительность 32-пакетного сигнала: **0,48736 с**.
+
+`cProfile` использован для поиска затрат. Числа скорости ниже получены
+отдельно через `time.perf_counter()` без профилировщика. Для каждого прохода
+записаны повторные измерения; указан средний по порядку из повторов.
+
+| Замер | Исходный декодер | Прогретый Numba | Ускорение |
+|---|---:|---:|---:|
+| 32 пакета, приём и видеозаголовок | 2,690 с; фактор **5,520** | 0,0635 с; фактор **0,130** | **42,36×** |
+| Только Витерби, те же 32 мягких слова | 2,125 с; фактор **4,360** | 0,0270 с; фактор **0,055** | **78,68×** |
+| 256 пакетов, длинный контроль | фактор **4,518** | фактор **0,133** | 34,1× |
+| 40 пакетов, CRC → внешний FEC → сборка видеокадра | фактор **4,446** | фактор **0,131** | **33,90×** |
+
+Первый полный проход с компиляцией Numba занял **0,929 с**; это отдельная
+стоимость запуска, не включённая в прогретый фактор. Numba 0.61.2 и
+llvmlite 0.44.0 взяты из уже существующего локального набора проекта.
+Компиляция работает с `fastmath=False`, а отсутствие Numba даёт явную ошибку
+выбранного JIT-режима. После отказа CRC другой декодер не запускается.
+Эталонные битовые выходы, решения QPSK, CRC, пакеты и SHA видеоданных до и
+после совпали. Длинный поток также совпал на всех 256 пакетах.
+
+Предварительный `cProfile` исходного 32-пакетного пути относил 2,743 из
+3,196 с профилируемого времени к Витерби; внутри было 262 336 вызовов
+`argmin`. После JIT основными расходами стали поиск преамбулы и оценка
+несущей. Для нового 40-пакетного пути профиль приведён отдельно:
+
+| Этап | Время `cProfile`, мс | Доля 91,4 мс | Вызовы | Основной массив или копия |
+|---|---:|---:|---:|---|
+| Витерби вместе с вызовом декодера | 34,8 | 38,1% | 40 | `choices`: 524 672 байта на полный пакет внутри Numba |
+| Поиск преамбулы | 27,1 | 29,7% | 40 | короткие срезы по 1280 символам |
+| Коррекция фазы/частоты | 11,3 | 12,4% | 120 | копия только текущего заголовка или тела |
+| Оценка фазы/частоты | 9,3 | 10,2% | 80 | временные массивы пилота и заголовка |
+| Снятие прокалывания | 1,59 | 1,7% | 40 | 16 396 `float64`, около 131 Кбайт на пакет |
+| Решения QPSK | 0,56 | 0,6% | 40 | около 98 Кбайт мягких значений |
+| Разбор `protocol.packet` и CRC | 0,33 | 0,4% | 40 | до 1024 байт пакета |
+| Сборщик внешнего FEC | 1,61 | 1,8% | 36 | буфер максимум 8 блоков; четыре матричных восстановления |
+| Выдача фрагмента видеосборщику | 0,36 | 0,4% | 32 | повторная упаковка в байты не выполняется |
+| RRC | отдельно | вне пути | один контроль | 11,09 мс на один пакет при известных тактах |
+| Восстановление тактов и слежение из IQ | `NOT_IMPLEMENTED` | вне пути | 0 | не измерялись |
+
+Строки со вложенными вызовами нельзя складывать: например, снятие
+прокалывания входит во время декодера. Одиночный RRC-контроль с 16 выборками
+на символ прошёл CRC, но его 11,09 мс нельзя прибавлять к потоку как
+доказательство готового IQ-приёмника. `tracemalloc` показал пик Python-памяти
+13,69 Мбайт до правок и 1,07 Мбайт после на 32 пакетах. Он не учитывает всю
+нативную память NumPy и Numba.
+
+## Защита от стирания пакета
+
+Внешний систематический код использует уже существующую в проекте
+арифметику GF(256) из `protocol/packet_erasure_fec.py`. Упаковка Lab028 не
+используется. Новый символ содержит 16 байт метаданных блока, 2 байта длины,
+4 байта времени создания кадра и проверенный 13-байтный видеозаголовок.
+Максимум данных видео: **977 байт** в полном payload PHY 1012 байт.
+Все внешние символы имеют одинаковую длину для точного восстановления
+последнего короткого фрагмента. Внешний код восстанавливает стирания после
+строгого CRC; он не исправляет неизвестные ошибочные биты внутри пакета.
+
+Систематический фрагмент сразу передаётся сборщику. При потерях декодирование
+блока начинается после получения любых `K` различных символов. Полученный
+после 300 мс фрагмент отвергается по времени создания кадра. Буфер
+ограничен восемью блоками; дубли и противоречивые метаданные проверяются.
+Тесты подтвердили одну потерю, потери до `R`, отказ при числе потерь больше
+`R`, точное восстановление байтов и короткого последнего фрагмента.
+
+Для полных пакетов расчётный бюджет без пауз:
+
+| K+R | Доля проверочных пакетов | 2/3: чистое видео, кбит/с | 3/4: чистое видео, кбит/с | Время полного блока 2/3, мс |
+|---|---:|---:|---:|---:|
+| 8+1 | 11,11% | 456,176 | 501,122 | 137,07 |
+| 8+2 | 20,00% | 410,558 | 451,010 | 152,30 |
+| 12+2 | 14,29% | 439,884 | 483,225 | 213,22 |
+| 12+3 | 20,00% | 410,558 | 451,010 | 228,45 |
+| 16+2 | 11,11% | 456,176 | 501,122 | 274,14 |
+| 16+4 | 20,00% | 410,558 | 451,010 | 304,60 |
+
+Это предел для полного блока с заполненными пакетами. Последний частичный
+блок и защита опорного кадра меняют фактическую долю чётности. Например,
+для NORMAL 8+1 с усилением опорных блоков расчёт по числу реально созданных
+символов в двух окнах даёт **424,922 / 425,142 кбит/с**. Пик SHORT_GOP 400k
+за одну секунду, худший из двух окон: **408,8 кбит/с**. Запас в этой паре
+всего около 1,04, без учёта ошибок внутреннего PHY. Блок 16+4 из 20 полных
+пакетов занимает 304,6 мс, уже больше срока кадра без ожидания накопления
+данных. Для каждого прогона модель учитывает готовность исходных фрагментов,
+момент появления чётности и истечение срока.
+
+## Потери, перемежение и опорные кадры
+
+В модели использованы настоящие H.264 пакеты, короткий GOP, ограниченный
+сборщик VIDEO-002 и декодер PyAV. Случайные потери применяются независимо
+к передаваемым радиопакетам; 1440 основных прогонов покрывают ROBUST,
+NORMAL и HIGH QUALITY, два окна, обе скорости внутреннего FEC, шесть схем,
+равномерную и усиленную защиту, уровни 0/1/2/5/10/20% и серии 2/5/10.
+Для выбора NORMAL дополнительно выполнены 180 прогонов на пяти фиксированных
+затравках `20260916…20260920`. Числа ниже относятся к 10 окнам по 60 кадров.
+
+| Внешняя защита, inner 2/3 | 1%: показано / 600 | 5%: показано / 600 | 10%: показано / 600 | 5%: кадр/с | 5%: доля потерь кадров |
+|---|---:|---:|---:|---:|---:|
+| 8+1 одинаковая | 594 | 452 | 264 | 7,53 | 24,7% |
+| 8+1, опорный блок +1 parity | 591 | **498** | 330 | **8,30** | **17,0%** |
+| 8+2 одинаковая | 580 | 484 | **363** | 8,07 | 19,3% |
+
+При 1% лучшая доля в этой выборке у одинаковой 8+1; при 5% у усиленной
+8+1; при 10% у одинаковой 8+2. Эти короткие реализации не дают оценки
+длительного канала. В варианте 8+1 с усилением среднее время от первого
+непоказанного кадра до следующего показанного опорного кадра при 5%
+составило **535 мс** против **665 мс** у одинаковой 8+1. Это показатель
+данной модели и затравок, а не обещание восстановления при любой серии.
+
+В отдельном контроле две потери источников **одного блока опорного кадра**
+дали 55/60 показанных кадров в каждом окне при 8+1 без усиления; следующий
+опорный кадр появился через 652/668 мс. При усилении блока до двух parity
+получено 60/60, два фрагмента восстановлены до срока и провала изображения
+не было. Одну потерю восстанавливали оба варианта.
+
+Проверка перемежения глубины 2 отклонена. Даже при 0% потерь она показала
+лишь 24/120 кадров для 8+1, 21/120 для 8+2 и 3/120 для 12+2 в NORMAL:
+ожидание фрагментов следующего блока нарушило срок 300 мс. Без перемежения
+при 0% эти схемы показали 120/120. Серии 2/5/10 сохранены отдельно в JSON;
+уменьшение влияния серии не окупило задержку в этом способе чередования.
+
+При одинаковых заданных стираниях пакетов inner FEC 2/3 и 3/4 дали одинаковые
+числа показанных кадров для трёх сравниваемых схем NORMAL на пяти затравках;
+3/4 даёт больше расчётной ёмкости. Эта модель не создаёт битовых ошибок.
+Контроль VIDEO-003 при 3 dB `Eb/N0` на пакетах меньшей длины дал 13/32 CRC
+для 2/3 против 3/32 для 3/4. Его нельзя переносить как точную вероятность
+для максимальных пакетов, но оснований заменить первый диагностический
+кандидат на 3/4 пока нет.
+
+## CODE QUALITY AUDIT
+
+Исходная инвентаризация восьми модулей: 1967 строк, 70 функций. Сейчас те же
+восемь модулей содержат 2008 строк и 72 функции; новые модули Витерби и
+внешнего FEC содержат ещё 309 строк и 11 функций. Размер кода здесь не
+критерий качества. Рабочая цепочка: символы → преамбула/PHY → QPSK → снятие
+прокалывания → Витерби → CRC → внешний FEC → свежий видеофрагмент.
+
+| ITEM | BEFORE | ACTION | AFTER | EFFECT |
+|---|---|---|---|---|
+| Витерби | Python-цикл, 262 336 `argmin` за 32 пакета | JIT со скалярным выбором ветви и `fastmath=False` | те же биты | 78,68× для Витерби |
+| Коррекция несущей | два прохода по всему оставшемуся потоку на пакет | ограничена заголовком и текущим телом | те же пакеты/CRC | фактор пути 5,520 → 0,130 вместе с JIT |
+| Проверка конечности | сканирование всего суффикса на каждом пакете | проверяется кандидат и его тело | повреждение текущего пакета отвергается | 256 пакетов: фактор 0,288 → 0,133 |
+| Маска FEC и преамбула | повторные массивы и PRBS7 | точный арифметический счёт, ограниченный кеш неизменяемых масок | те же кодовые длины и биты | меньше выделений |
+| Сборщик блоков | состояние росло с числом блоков | ограничен восемью блоками, поздние повторы игнорируются | строгие кадры и счётчики без изменений | ограничена память |
+| Подача v2-фрагмента | требовала бы повторной упаковки под v1 | отдельный проверяемый вход `offer_fragment` | v1 сохранён | меньше копий в горячем пути |
+
+Классификация существенных проверок: **A, production safety**: длины PHY и
+FEC, конечность текущих символов, метаданные блока, возраст, границы буфера,
+CRC и отказ от старого кадра оставлены. **B, development assertion**:
+сравнение SHA, точных битов и ожидаемого числа кадров живёт в тестах и
+инструментах опыта. **C, offline diagnostic**: `cProfile`, `tracemalloc`,
+JSON и исходные H.264 сравнения находятся в `tools/`, вне приёмника.
+**D, duplicated check**: повторный проход по всему суффиксу убран;
+проверка полей на публичном входе `offer_fragment` оставлена, хотя текущий
+вызывающий код уже разобрал заголовок. **E, hot-loop check**: проверка
+конечности вынесена из полного потока в границу текущего пакета, а
+Numba-цикл Витерби не строит NumPy-массивы на каждом шаге.
+
+| Существенная runtime-проверка | Место | Категория | Решение |
+|---|---|---|---|
+| PHY-длина, версия и CRC пакета | `video003_modem`, `packet` | A | Оставить до выдачи данных внешнему FEC |
+| Длина и конечность мягких значений | `punctured_fec` | A/E | Оставить один раз перед решёткой |
+| Диапазоны K/R, индекс, поток и длина символа | `video004_erasure` | A | Оставить перед накоплением блока |
+| Время создания и возраст фрагмента | `video004_erasure`, `video_stream_transport` | A | Оставить; после 300 мс не выдавать |
+| Предел буфера и повтор старого кадра | оба сборщика | A | Оставить с ограничением 8 блоков и 2 кадров |
+| SHA эталона, точные биты и ожидаемые счётчики | `tests/`, `tools/video004_*` | B/C | Держать вне приёмника |
+| Повторная проверка полей на публичном входе | `FrameReassembler.offer_fragment` | D → A | Оставить как защиту от другого вызывающего кода |
+| Сканирование всего хвоста потока | прежний `receive_frame` | E | Заменить проверкой текущего кандидата и тела |
+
+| ITEM | LOCATION | WHY SUSPICIOUS | ACTION |
+|---|---|---|---|
+| Сборка `np.concatenate` и SHA эталона | `tools/video004_benchmark.py` | массивы и знание исходного пакета | **KEEP** только в генераторе и проверке после CRC |
+| RRC roundtrip | `protocol/video003_modem.py` | не является поточным IQ-приёмом | **KEEP** как отдельный контроль; вне горячего пути |
+| Упаковка Lab028 | `protocol/packet_erasure_fec.py` | лишний заголовок и иной формат пакета | **KEEP** для старых лаб; новый видеоформат её не вызывает |
+| `_linear_combine` | `protocol/packet_erasure_fec.py` | внутренний API другого модуля | **KEEP** проверенную арифметику; публичный общий API отложить |
+| Преобразования в решётке | прежний `convolutional_fec.py` | массивы на каждом шаге | **REWRITE** в отдельном JIT-варианте; старый код сохранён как эталон |
+| Большая функция `simulate` | `tools/video004_transport.py` | смешивает график передачи, потери и H.264 | **KEEP** как автономную модель с фиксированными входами; не импортируется рабочим приёмником |
+
+Генерация сигнала, `np.concatenate`, SHA и сравнение с эталоном остались в
+`tools/` как диагностика. В критическом пути нет
+графиков, исторических Lab-проверок, verifier, подробного JSON и сравнения с
+исходными пакетами. Нужные проверки повреждённых данных не удалялись.
+
+После правок повторены модемные векторы, FEC/CRC, тесты стираний,
+1440 моделей потерь, 48 случаев перемежения, 180 случаев пяти затравок и
+оба замера производительности. Сравнение копии 1440 результатов до и после
+аудита: показанные кадры, возраст и восстановления совпали; изменилось
+лишь исправленное диагностическое поле числа неполных блоков в 480 строках.
+`BEHAVIOR EQUIVALENT = YES` для строгого приёма и показа кадров.
+
+`RUFF = NOT_RUN — TOOL NOT INSTALLED`.
+`coverage`, `mypy`, `pyright`, `vulture`, `radon` также `NOT_RUN — TOOL NOT INSTALLED`.
+Постоянные новые зависимости не устанавливались. Правило полного обзора после
+крупного этапа сохраняется для CONTROL-001/002; мелким правкам достаточно
+`pytest`, доступного `ruff` и `git diff --check`.
+
+## Машинные результаты и повторение
+
+Все файлы находятся в `data/processed/video004/`: канонический 32-пакетный
+сигнал и его manifest, `benchmark_before.json`, `benchmark_after.json`,
+`viterbi_benchmark.json`, 256-пакетный сигнал и `benchmark_256.json`,
+40-пакетный `pipeline_benchmark.json`, `transport_results.json`,
+`interleaving_results.json`, `normal_seed_sweep.json` и
+`keyframe_recovery.json`. Эталонные пакеты не передаются декодеру.
+
+Из корня VIDEO worktree, с доступной Numba 0.61.2:
+
+```powershell
+python -B -X utf8 -m tools.video004_benchmark --phase after --numba-packages C:\Users\user\Desktop\projects\SDR_Rover\.lab053_cpu_runtime\packages
+python -B -X utf8 -m tools.video004_viterbi_benchmark --numba-packages C:\Users\user\Desktop\projects\SDR_Rover\.lab053_cpu_runtime\packages
+python -B -X utf8 -m tools.video004_longrun --numba-packages C:\Users\user\Desktop\projects\SDR_Rover\.lab053_cpu_runtime\packages
+python -B -X utf8 -m tools.video004_pipeline_benchmark --numba-packages C:\Users\user\Desktop\projects\SDR_Rover\.lab053_cpu_runtime\packages
+python -B -X utf8 -m tools.video004_transport
+python -B -X utf8 -m tools.video004_interleaving
+python -B -X utf8 -m tools.video004_seed_sweep
+python -B -X utf8 -m tools.video004_keyframe
+python -B -X utf8 -m tools.video_gate --numba-packages C:\Users\user\Desktop\projects\SDR_Rover\.lab053_cpu_runtime\packages
+```
+
+Старый `benchmark_before.json` повторно не создаётся после правок: он
+фиксирует исходный код VIDEO-003 на том же сигнале. На другой машине нужно
+установить зависимости из `requirements-video.txt`; абсолютный путь локальных
+пакетов Numba в командах относится только к этому ПК. Замер скорости следует
+повторять на целевом Raspberry/Jetson отдельно.
+
+## Обязательные поля результата
+
+| Поле | Значение |
+|---|---|
+| `VIDEO-004 STATUS` | `PARTIAL` |
+| `QPSK 500K FEC 2/3 INITIAL REALTIME FACTOR` | **5,520**, 32 пакета, доступный путь VIDEO-003 |
+| `OPTIMIZED REALTIME FACTOR` | **0,130**, тот же 32-пакетный сигнал, прогретый путь |
+| `REALTIME TARGET >=1.5X` | `PASS` для доступного пути; также пройден предпочтительный фактор ≤0,50 |
+| `MAIN BOTTLENECK BEFORE OPTIMIZATION` | Витерби, 2,743/3,196 с по `cProfile` |
+| `MAIN OPTIMIZATIONS` | JIT без `fastmath`; обработка только текущего пакета; ограниченная проверка конечности; кеш преамбулы и маски |
+| `JIT FIRST RUN TIME` | 0,929 с для первого полного 32-пакетного прохода |
+| `WARM RUN TIME` | медиана 0,0635 с на 32 пакета |
+| `STEADY-STATE REALTIME FACTOR` | **0,130** |
+| `VITERBI REALTIME FACTOR BEFORE / AFTER` | **4,360 / 0,055** |
+| `AVAILABLE PIPELINE REALTIME FACTOR BEFORE / AFTER` | **4,446 / 0,131** на 40 пакетах с четырьмя стираниями |
+| `VITERBI SPEEDUP` | **78,68×** |
+| `FULL AVAILABLE PIPELINE SPEEDUP` | **33,90×** |
+| `TRANSPORT ERASURE CODE` | Систематический GF(256), отдельная видеооболочка |
+| `BEST DATA/PARITY CONFIGURATION` | 8+1 с дополнительным parity для опорного блока в диапазоне 1–5% данной модели; 8+2 одинаковая лучше при 10% |
+| `PACKET LOSS 1%: DISPLAYED FPS / FRAME LOSS` | 8+1 с усилением: **9,85 кадр/с; 1,5%**, 591/600 |
+| `PACKET LOSS 5%: DISPLAYED FPS / FRAME LOSS` | **8,30 кадр/с; 17,0%**, 498/600 |
+| `PACKET LOSS 10%: DISPLAYED FPS / FRAME LOSS` | 8+1 с усилением: **5,50 кадр/с; 45,0%**; 8+2 одинаковая: 6,05 кадр/с; 39,5% |
+| `BURST LOSS RESULT` | Глубина перемежения 2 непригодна при сроке 300 мс: даже при 0% потерь лишь 24/120 кадров для 8+1 |
+| `KEYFRAME RECOVERY` | Две потери в одном блоке: 55/60 без усиления, 60/60 с усилением, в обоих окнах |
+| `NET VIDEO RATE AFTER OUTER FEC` | 8+1 с усилением NORMAL: **424,922 / 425,142 кбит/с**; равномерная 8+2: около 409,4 / 409,8 кбит/с с учётом частичного блока |
+| `NORMAL 640x360/10 SUPPORTED IN SOFTWARE MODEL` | `NO` для устойчивой работы на всём интервале 1–5% с инженерным запасом |
+| `INNER FEC 2/3 VS 3/4 RESULT` | При заданных стираниях кадры одинаковы в сравниваемых схемах; более слабый внутренний код 3/4 не подтвердил общего выигрыша с учётом AWGN-контроля VIDEO-003 |
+| `BEST NEXT RF CANDIDATE` | Отложен; диагностический программный кандидат: QPSK 500 ксимв/с, inner 2/3, outer 8+1 с усилением опорного блока, SHORT_GOP 400k |
+| `WHY` | Порог CPU выполнен, но при 5% потерь не показаны 102/600 кадров, запас скорости около 1,04 и нет проверки полного IQ/RF-приёмника |
+| `TESTS BEFORE / AFTER` | VIDEO-003: 123; до заключительного обзора VIDEO-004: 143; после: **145 passed** |
+| `BEHAVIOR EQUIVALENT` | `YES` для битов, CRC, пакетов и кадров на фиксированных входах |
+| `HOT PATH REMAINING BOTTLENECK` | По `cProfile`: Витерби 34,8 мс, поиск преамбулы 27,1 мс на 40 пакетов; отсутствуют timing recovery и IQ carrier tracking |
+| `VIDEO-SPECIFIC GATE` | **PASS: 145 тестов**, сверка артефактов и повторный замер |
+| `RF TX` | `0` |
+| `SDR HARDWARE` | `NOT ACCESSED` |
+| `COMMIT / PUSH` | `NOT PERFORMED / NOT PERFORMED` |
+
+Отдельный общий `python tools/quick_gate.py` дал 1070 passed, 2 skipped и
+1 failed: в этом worktree отсутствует исторический
+`data/raw/lab064/tx_metadata.json`, нужный проверке Lab065. Целевой VIDEO-шлюз
+прошёл: 145 passed. Это разные наборы проверок.
+
+Следующий RF-опыт требует отдельного прямого разрешения. VIDEO-005 в этой
+работе не начинается.