BLUEPRINT

Глава 8. Дорожная Карта

В этой главе очерчиваются границы первой фазы и намечается эволюция в известных направлениях. Каждый пункт указывает область влияния на текущую архитектуру, чтобы будущие проекты сходились направленно.

8.1 Объём первой фазы

Поставка первой фазы Fayger как минимум:

Стабильные контракты трёх слоёв (Loader / Runtime / Adapter).
Пятичастный формат артефакта BuF с детерминированным CBOR Manifest / Section_Index.
Цепочка загрузки: Read(Header/Manifest/Index) → Parse → Verify(Structural) → Verify(Digest of Header/Manifest/Index) → Verify(Signature) → Negotiate Version → Select(Sections by LoadProfile) → Resolve → Read(Selected Section Bodies)? → HandOff.
Абстракция BuF_Source с поддержкой любого бэкенда хранения (локальный, сеть, объектное хранилище, пользовательский).
Частичная загрузка (выбор Sections по профилю) и ленивая загрузка (Eager / Lazy LoadStrategy), покрывающие требования по размеру и подгрузке для ограниченных терминалов (дроны, камеры).
Интерпретируемый путь исполнения; конечный автомат жизненного цикла BuF_Instance и изоляция сбоев.
8 категорий Universal_Instruction и четыре встроенных Platform_Adapter (десктоп / сервер / браузер / In-App).
Единая модель ошибок и шина событий наблюдаемости; ошибки loader несут тег phase.
Проверка подписи, режим обязательной подписи и видимость обновлений доверенных корней.

8.2 Не-цели первой фазы

Чтобы ограничить сложность фазы 1, явно не поставляется:

Разделяемая память и IPC между BuF_Instances.
JIT-компиляция и генерация машинного кода.
Распределённое планирование и многоузловая кооперация Fayger.
Дифференциальная дистрибуция BuF и слоистый кеш между артефактами (частичная загрузка покрывает выбор Sections внутри артефакта; межартефактная дифф-разделяемость и протокол Distribution отложены).
Встроенный удалённый репозиторий / протокол Distribution.

Не-цель — не «никогда не нужно», а «сегодня не на поверхности контракта». Будущие фазы не должны ломать существующие контракты.

8.3 Фаза 2: производительность исполнения

Направление: добавить более эффективные пути исполнения, не ломая Runtime_Interface.

8.3.1 Абстракция ExecutionStrategy

Вынести «как исполнять семантику BuF» в стратегию:

interface ExecutionStrategy {
  prepare(obj: BuFObject) -> PreparedExecutable
  step(exec: PreparedExecutable, ctx: ExecutionContext) -> StepResult
}

Фаза 1 поставляет Interpreter как одну из стратегий. В дальнейшем могут сосуществовать:

JIT: компилировать промежуточное представление code section в машинный код.
AOT: производить машинный код при загрузке (подходит для release).
HybridTier: интерпретация → зондирование → компиляция.

Выбор стратегии — внутри Runtime_Implementation; внешний контракт Runtime_Interface не затрагивается.

8.3.2 Наблюдаемость производительности

Новые категории событий:

ExecutionMetric: выборки интерпретации / компиляции / GC.
TierTransition: переход между уровнями ярусного исполнения.

Конкретные стратегии вовне не выставляются, но их эффект наблюдаем.

8.4 Фаза 3: дистрибуция и кеш

8.4.1 Слои и чанки между артефактами

Фаза 1 уже поддерживает чтение «по требованию» с гранулярностью Section внутри одного BuF (Lazy). Позже вводится межартефактное слойное разделение:

Ресурсы, разделяемые между BuFs (стандартная библиотека, веса моделей), выделяются в независимые слои.
Manifest получает опциональный layer_refs, ссылающийся на Sections в других артефактах.
Протокол дистрибуции получает слоистые ресурсы общим способом; локальный кеш-хит даёт повторное использование между BuFs.

Это требует опциональных полей в Manifest и, соответственно, минорного бампа schema_version. Существующие BuFs не затрагиваются (путь совместимости в §8.7).

8.4.2 Протокол дистрибуции

Введение лёгкого протокола дистрибуции (со ссылкой на OCI Distribution Spec):

Три шага: discover / pull / verify.
Сам протокол не находится в процессе Fayger; его реализует отдельный компонент. Fayger потребляет только chunks, которые тот производит.

8.4.3 Локальный кеш

Для BuFs, уже загруженных и прошедших проверку подписи, кешируется результат парсинга Manifest и Section между процессами. При попадании повторно проверяется подпись (защита от отравления кеша).

8.5 Фаза 4: межинстансная кооперация

8.5.1 Разделяемая память (контролируемая)

Несколько BuF_Instances внутри одного Fayger могут разделять область памяти:

Явно объявить capability shared_memory в Manifest.
Слой исполнения централизованно выделяет области и предоставляет их по разрешённым capabilities.
Разделяемые области под мониторингом квот; нарушения вызывают приостановку.

8.5.2 Протокол IPC

Межинстансная передача сообщений (в одном процессе или в одном Fayger):

Выражена как новая категория ipc Universal_Instruction.
По умолчанию запрещено; Manifest должен объявить набор ID партнёров или topic'и.

8.5.3 Сборка зависимостей внутри одного Fayger

Один BuF может ссылаться на другие BuFs как на зависимости:

Фаза Resolve поддерживает рекурсивное разрешение.
Граф зависимостей выражается полем dependencies Manifest.
Циклические зависимости отклоняются в Resolve.

8.6 Фаза 5: распределённость

Направление: многоузловая кооперация Fayger. Не входит в фазу 1, но оставлены поля для манёвра:

ID BuF_Instance должны быть уникально адресуемы между узлами.
Метки времени Lifecycle Events должны выравниваться с внешними системами трейсинга.
TLV-кодирование Universal_Instruction уже поддерживает сетевую транспортировку; «удалённый диспетчинг» может быть отдельной реализацией Adapter.

8.7 Стратегия совместимости

Каждая эволюция должна следовать этим правилам; иначе это ломающее изменение:

Версия Runtime_Interface. Бамп по SemVer при добавлении методов или изменении семантики. BuF_Manifest выражает свою минимальную зависимость через runtime_interface_min.
Версия BuF schema. Добавление опциональных полей → минорный бамп; добавление обязательных или изменение семантики существующих → мажорный бамп.
Стабильность кодов ошибок. Опубликованные коды не переиспользуются и не меняют семантику; новые добавлять можно.
Категории Universal_Instruction. Существующие 8 не меняют номера; новые используют зарезервированные биты.
Поток депрекации. Сначала пометить deprecation_notice; при загрузке выводится подсказка, но загрузка разрешена; убрать только после хотя бы одной мажорной версии.

8.8 Рекомендации по инструментарию

Для поддержания долгосрочной эволюции рекомендуем:

Статическая проверка направления зависимостей. Запретить слою исполнения импортировать тип Platform_Adapter и заглядывать во внутренности loader. Реализуемо через ArchUnit / dep-cruiser / собственные lint'ы.
Базовый PBT-набор. Зафиксировать свойства корректности плана (эквивалентность «туда-обратно», переходы автомата, цепочки ошибок, алгебра capabilities и т. д.) как кросс-языковой Conformance Suite, чтобы любая Runtime_Implementation могла себя проверить.
Валидатор CBOR Manifest. Проверять, что Manifest использует детерминированный CBOR; недетерминированные кодировки — несоответствие.
Health-check дескриптора Adapter. При регистрации сразу проверять согласованность supported_capabilities и supported_instructions (например, минимальное замыкание битов capabilities относительно требуемых инструкциями).

8.9 Сводная дорожная карта

Фаза	Ключевые направления	Основной слой	Влияние на совместимость
Фаза 1 (текущая)	Контракты трёх слоёв, интерпретируемое исполнение, четыре встроенных адаптера, подписи, частичная загрузка по Section, Eager/Lazy, абстракция BuF_Source	Три слоя + сквозные	—
Фаза 2	ExecutionStrategy / JIT / AOT	Runtime	Совместимо (дополнения)
Фаза 3	Слоистость между артефактами / Distribution / локальный кеш	Loader	Совместимо (минор)
Фаза 4	Разделяемая память / IPC / граф зависимостей	Runtime + Loader	Совместимо (дополнения)
Фаза 5	Многоузловая кооперация	Adapter (удалённый диспетчинг)	Совместимо (дополнения)

Документы дизайна последующих фаз будут публиковаться как самостоятельные планы и разделять с настоящим планом одну и ту же терминологию и контракты.