Модель Avro `[ПО ПАМЯТИ, НЕ ПРОВЕРЕНО]`: каждая запись пишется против схемы писателя; читатель обязан добыть **именно ту схему писателя**, по которой записано, и согласовать её со своей схемой читателя. Обычно — по отпечатку (fingerprint), который лежит в данных, через реестр схем.

Чтобы это работало у нас, читатель должен:

Свод `[ИЗ СВОДА]`: «в git-репозитории это стоит указателя, и история схемы лежит в той же истории, что и данные». Но:

Avro требует: публиковать машинно-читаемый артефакт схемы с данными (или реестр), учить читателей его доставать и согласовывать, версионировать этот артефакт, держать дисциплину отпечатков. Это большая машинерия — ради выгоды, которую у нас некому потреблять (внешних читателей ноль `[ИЗ СВОДА]`, а своим согласование схем не нужно: писатель и читатель — один бинарник).

Терпимый читатель требует: читать узкими view, игнорировать незнакомые поля, отсутствующее трактовать как default. **Это уже написано** (`wire.rs`). Маржинальная стоимость — около нуля.

**Ответ на вопрос: Avro для нас дороже терпимого читателя, заметно и по машинерии, и по предпосылкам.** Настоящий (и полезный) урок Avro — не «возить схему с данными», а «сделать схему машинно-читаемым артефактом вообще». Этого артефакта у каталога сегодня нет; фикс — опубликовать JSON Schema / JTD (паттерн уже есть в `vibe-cli/resources/`), а не внедрять разрешение схем Avro.

Свод `[ИЗ СВОДА]`: для скаляров присутствие вернули через ~5 лет, для списков и словарей — «так и не вернули … слиты навсегда», и подаёт это как незавершённость.

Я утверждаю, что это **осознанный отказ**, и вот цена различимости для списка `[ПО ПАМЯТИ, НЕ ПРОВЕРЕНО]`:

Для proto3 цена особенно высока: их двоичный формат не выделяет присутствие для repeated-полей без явного бокового маркера, и реставрация ломала бы компактность и обратную совместимость с существующими данными. Отказ рационален.

Ключевое различие, которое свод не провёл: **присутствие нужно человеко-написанным данным, где «я не заполнил» реально, и почти не нужно машинно-сгенерированным, где каждое поле детерминированно вычислено.**

Каталог пишет индексатор. Он всегда знает значение каждого поля — читает его из `vibe.toml` пакета. Поэтому «отсутствует» для каталожного поля — не легитимное «неизвестно», а всегда «вычислено как пустое». Различимость пусто/нет **ничего не покупает**, потому что состояние «нет» никогда не наступает законно.

Конкретно по нашим полям `[ИЗ ДЕРЕВА]`: `authors`, `keywords`, `requires.packages`, `provides.capabilities`, `features`, `i18n.available` — все вычисляются индексатором из манифеста; «нет» у них не бывает. Даже `requires_any` (`entry/mod.rs:96`) — «зависимость any-of не задана» — это ограничение, а не присутствие.

У манифеста `vibe.toml`, который пишет человек `[ИЗ СВОДА]`, «я не указал» — реальное состояние. Там `authors = []` (явно: авторов нет) против отсутствующего `authors` (не записано) — **осмысленное** различие. И TOML здесь помогает, а не мешает: отсутствие null в TOML — это **фича**, она принуждает выражать трёхзначность через «нет ключа» против `[]`, без null-сигнала, который можно перетолковать. JSON и TOML соглашаются в механизме.

**Различимость пусто/нет для списков нам для каталога НЕ нужна.** 21 поле со `skip_serializing_if = "...is_empty"` безопасны для машинных данных. Присутствие стоит сохранять только там, где «неизвестно» легитимно — то есть в человеко-написанном манифесте. И свод сам к этому приходит в рекомендации №2 (`null не нужен: в TOML его нет`) — но он не развёл, что для каталога это безразлично, а для манифеста — обязательно, и фиксы там разные.

Соседне-тегированная форма, родная для serde:

(Одно-ключевая форма `{"directory":{…}}` / `{"file":{…}}` тоже возможна, но требует ручной ser/deser — serde не даёт её из коробки; adjacent-тег — серде-нативный её аналог.)

**Форма A.** Один атрибут от нынешнего состояния, стандарт во всех языках схем, дешёвая, и — критически — устраняет блокер А6 («тип невыразим в языке схемы»): он невыразим **только** пока мы держим `untagged`. Если ожидается рост числа вариантов — Форма D.

В тот момент, когда она **отображает нераспознанный вход в определённое значение, на котором потребитель потом действует** (паттерн Cloudflare «score zero»). Молчаливый default неизвестного значения enum — единственная самая опасная терпимость. Добавление (новые поля, новая длина, новые ключи карты) — терпимо; нарушение типа — нет; новые значения enum — не молча в default.

«Строго на двери, терпимо дальше» — верно, но **недоспецифицировано на enum'ах**. Я бы уточнил: дверь (`vibe.toml`) отвергает и неизвестные значения enum, и опечатки; каталог (вниз по потоку) терпит незнакомые **поля**, но всё равно **не** молча дефолтит неизвестные **значения** enum — несёт их как `Unknown`, чтобы будущий читатель мог ими воспользоваться. Это более острая граница, чем просто «терпимо дальше».

Свод `[ИЗ СВОДА]`: JSON-кодек protobuf по умолчанию отвергает незнакомые поля, а на жалобы ответ — «используйте двоичную»; мы наследуем весь набор проблем их JSON без их выхода.

Я не согласен с рамкой. «JSON-проблема» protobuf в том, что их JSON строг, а двоичный — терпим, и недовольных отсылают в двоичный. **Нас никто не заставляет быть строгими в JSON:** serde позволяет выбрать `deny_unknown_fields` или нет. Сейчас мы **сами выбрали** строгость в 15 местах своего читателя и терпимость — в клиенте. Так что «выход» (терпимое чтение) тривиально доступен нам убиранием одного атрибута — двоичный формат для выхода не нужен. Свод подаёт так, будто двоичный protobuf — единственный выход из строгого JSON; для нас выход — терпимый JSON, и он бесплатен.

Что мы реально наследуем от JSON-без-схемы: не «проблемы protobuf», а проще — **в JSON нет схемы, поэтому дисциплина эволюции живёт целиком в головах + чекере.** Это и есть урок Cloudflare `[ИЗ СВОДА]`: ужесточить приём собственных сгенерированных файлов так же, как пользовательский ввод. И — повторю из §1 — артефакт схемы для каталога у нас отсутствует, хотя способность его публиковать в доме есть (`vibe-cli/resources/package-tree.schema.v1.json`).