Перейти к основному содержимому

Часть VII. Границы

24. Что формат не решает​

Каждый формат имеет границы. Ниже — честный список того, что IDF не покрывает, сгруппированный по типу.

Семантические границы.

  • Composite / polymorphic entities. Union-типы (сущность, которая может быть одним из нескольких видов) не выражаются через entity.kind. Авторы обходят это декомпозицией (N сущностей вместо одной с union). Открытая задача формата.
  • i18n за пределами fieldRole. Форматирование чисел, валют, дат через fieldRole — покрыто. Локализация layout'а, тональности labels, плюрализационных правил — не в формате. Host реализует локализацию сам.
  • Сложные графовые отношения. Онтология — древовидная (entity → fields). N-ary relationships и cyclic ссылки моделируются assignment-сущностями (bridge entities) — это выразительно, но требует от автора ручной декомпозиции.

Границы pixel-материализации.

  • Analytical UI. Чарты, heatmap'ы, 2D-редакторы, timeline-визуализации, map-canvas'ы — не кристаллизуются автоматически. Chart-primitive и map-primitive покрывают простые случаи; сложная аналитика требует authored custom canvas. Это не дефект формата — это явная декларация, что analytical UI является прерогативой host-приложения.
  • Capability mismatch. Добавление нового primitive kind без обновления адаптера производит fallback (SVG/text), не ошибку. Честно, но может давать visual regression. Adapter capability check at startup — открытая задача.

Инфраструктурные границы.

  • Cluster-friendly scheduler. Темпоральный слой — single-leader in-memory TimerQueue. Distributed execution (multi-master, fault-tolerant scheduling) не покрыт. Migration на replicated state machine — направление развития.
  • Supply chain и dependency management. Формат не описывает, как загружать домены, apply миграции, обрабатывать breaking changes онтологии между версиями. Это — host-level concern.
  • Backup, replication, disaster recovery. Φ — append-only log, легко backup'ируется, но конкретные BCDR-стратегии — вне формата.

Генеративные границы.

  • PDF / DOCX output. DocumentMaterializer даёт HTML/JSON граф; PDF/DOCX требуют server-side rendering пайплайна, который не формализован. Открытая задача формата.
  • Зрелость cross-stack конформанса. Независимые реализации на альтернативных стеках (systems-языки, native mobile) в активной разработке и проходят conformance на L1 + L2 против эталонных fixtures. Это даёт структурный стресс-тест формата на «не связан ли с React-specifics» для базовых слоёв (parser, Φ, fold, crystallize без Pattern Bank apply). Полный стресс L3 + L4 (четыре материализации, scheduler, irreversibility integrity, apply-фаза Pattern Bank'а) требует второй реализации этих слоёв — открытая задача.

Epistemic границы.

  • Anchoring promotion writer. Механизм превращения witness-of-heuristic в witness-of-proof через counterexample search — описан на уровне идеи, не формализован.
  • Pattern Bank: structure.apply для большинства stable паттернов. Три из тринадцати stable-паттернов имеют apply-функции; остальные — matching-only. Это не дефект, а постепенная экспансия банка через human review, но полная покрытость — открытое направление.
  • ML auto-learning паттернов. Claude Researcher pipeline предлагает паттерны, но automated promotion из candidate/ в stable/ через falsification-fixtures — не реализован.

Методологическая заметка. Манифест имеет три вида drift — числовой (счётчики устаревают), aspirational (заявлено, не реализовано), фактический (значения документа расходятся с кодом). v2 проектируется с зазором между нормой (этот документ) и статусом (implementation-status.md), чтобы drift'ы не накладывались. Норма стабильна; статус живой; архив неизменен.

25. Чем валидирован формат​

Короткая ссылка. Формат валидирован параллельным существованием нескольких различных доменов, разных UI-адаптеров и всех четырёх материализаций — все построенные через один движок.

Различные зоны силы формата проверены:

  • Транзакционные домены (booking, delivery, invest)
  • Коммуникационные домены (messenger, planning)
  • CRUD-масштаб и сложные permission-модели (sales)
  • Creative / analytical домены (lifequest, reflect, workflow)
  • Fintech с external ML-сервисами и irreversibility (invest, delivery)

Различные целевые среды проверены:

  • Corporate / data-dense эстетика
  • Handcrafted / sketch эстетика
  • Premium / minimal эстетика
  • Dashboard / enterprise-fintech эстетика

Все четыре материализации работают параллельно через viewer-scoping.

Детальный имплементационный статус — в implementation-status.md. Этот документ обновляется вместе с кодом; манифест остаётся timeless.