Формат и правила ведения — см. requirements-and-regression.md в репозитории development_directives. protocol — header-only библиотека (CRC-алгоритмы, проводные форматы пакетов заднего/головного борта) без собственной директории тестов вообще (find Libraries/protocol -iname "*test*" не находит ничего). Поэтому весь список ниже реконструирован напрямую из кода (fast_crc.hpp, cm_protocol.hpp, back_proto_prototype.hpp, hmi_proto_prototype.hpp) и целиком имеет статус ⚠ технический долг — тестов для этой библиотеки не существует в принципе. Требования сгруппированы по поведению, а не перечисляют каждую структурную деталь проводного формата по отдельности.

ID	Требование	Статус	Тест
REQ-1	FastCrc вычисляет стандартный табличный CRC-32 (256-элементная CRC32_TABLE, полином 0x04C11DB7): set_crc32_init_value() формирует начальное значение из стартового смещения (0, если start==0), fast_crc32() последовательно прогоняет буфер через ту же таблицу, начиная с этого значения	⚠ технический долг	у библиотеки нет тестов вообще; ни табличный алгоритм, ни его начальное значение ни разу не проверялись на known-answer тесте (например, CRC известной тестовой строки)
REQ-2	FastCrc::check_app_valid(file_path) открывает файл образа прошивки с диска, отклоняет его с сообщением в stderr при ошибке открытия, при размере меньше 4 байт и при ошибке чтения, читает содержимое целиком в буфер и в любом случае (успех/неуспех) освобождает его без утечки	⚠ технический долг	у библиотеки нет тестов вообще; ни один из путей отказа (файл не открылся / слишком мал / не прочитался) не воспроизведён
REQ-3	FastCrc::check(base, size) немедленно возвращает false, не вычисляя CRC, если первые 4 байта буфера равны ERASED_FLASH_MARKER (0xFFFFFFFF, признак стёртой flash-области); иначе вычисляет CRC32 по первым size-4 байтам и сравнивает с CRC, записанным в последних 4 байтах, возвращая true только при точном совпадении	⚠ технический долг	у библиотеки нет тестов вообще; ни валидный образ, ни повреждённый (несовпадающий CRC), ни "стёртый" (все 0xFF) образ не проверены
REQ-4	CustomCrc реализует простую 8-битную контрольную сумму с переполнением по модулю 256 (не настоящий CRC, несмотря на имя): calc() суммирует байты буфера, append() прибавляет к предыдущему значению, reset() не хранит состояния между вызовами	⚠ технический долг	у библиотеки нет тестов вообще; ни calc/append, ни их поведение при переполнении не проверены
REQ-5	BackBoardProtocol<RX_BASE,TX_BASE> и HeadBoardPrototype/hmi_proto_prototype.hpp определяют фиксированные, побайтово упакованные (#pragma pack(1)) форматы пакетов заднего и головного борта: 2-байтовая сигнатура-префикс (BACK_PREFIX/HMI_PREFIX = {0xE7,0xE7}), строго заданный порядок полей (ID/LEN/STATUS/FLAGS/TYPE/DATA/SESSION/CRC для заднего борта; ID/LEN/FLAGS/TYPE/DATA/CRC для головного, без STATUS и SESSION), и per-поле флаги участия в подсчёте CRC и/или длины пакета; размеры структур (BoardFlags=22 байта, HeadFlags=32 байта, DoorAndOtherFlags=1 байт) закреплены static_assert на этапе компиляции	⚠ технический долг	у библиотеки нет тестов вообще; ни один реальный пакет (валидный или намеренно повреждённый) не собирается и не разбирается через ProtocolEndpoint этой конфигурации в тесте — только компилируемость проверяется static_assert
REQ-6	Сопоставление тега типа пакета с полем полезной нагрузки (Packets-кортеж) покрывает не все объявленные значения перечисления типов: у заднего борта не описана запись для IDLE (0x10) — при её получении маппинг данных не определён; у головного борта из 35 объявленных HeadPacketTypes замаплены только 14 (TYPE0…TYPE13), остальные 21 значение не имеют записи в Packets	⚠ технический долг	у библиотеки нет тестов вообще; поведение при получении пакета с немаппированным типом (что должен вернуть/сделать парсер) не специфицировано ни одним тестом — неясно, является ли это осознанным пробелом протокола или недосмотром
REQ-7	BackBoardProtocol::test_diagnostics() регистрирует диагностический callback приёма, который на каждом новом снимке пакета сравнивает поля HeadFlags/тип пакета с ранее сохранённым состоянием и логирует через log_change/log_flag любые различия по m_dummy1[i], door_and_other и типу пакета	⚠ технический долг	у библиотеки нет тестов вообще; кроме того, в текущей реализации цикл, предназначенный для диффа m_dummy2, фактически повторно сравнивает и логирует m_dummy1[i] под меткой "m_dummy1[i]" — m_dummy2 не диффится и не логируется никогда; без теста этот, судя по всему, реальный дефект остаётся незамеченным (стоит завести отдельным багом, а не только как пробел в тестах)