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

Часть I. Тезис

1. IDF — формат описания приложения​

IDF — это формат данных, а не фреймворк. Приложение в IDF полностью описывается четырьмя сущностями:

  • Ontology — типизированное описание домена: сущности, поля, роли, инварианты, правила
  • Intents — конструктивные частицы изменения мира: declarations, не императивные handler'ы
  • Projections — авторские контракты на то, какие намерения образуют логически связный вид
  • Φ — лог событий (confirmed effects), порождённый выполнением намерений

Всё остальное — производное. Мир приложения = fold(Φ). Пользовательский интерфейс = функция от артефакта, который в свою очередь функция от онтологии, намерений, проекции и банка паттернов. Ни одна из этих функций не содержит скрытого состояния и не требует рантайм-интерпретации LLM.

Такое позиционирование ставит IDF в один ряд с OpenAPI и JSON-LD: это спецификация формы данных, а не исполняющая среда. Адаптер, рендерер, voice-материализатор, agent API, document-генератор — это читатели формата. Каждый читатель принимает тот же артефакт и превращает его в свою целевую среду (DOM, SSML, JSON-schema, HTML-граф).

Конформная реализация читает формат и предоставляет документированные гарантии: детерминизм кристаллизации, viewer-scoping, irreversibility high-risk действий, полный audit trail через Φ. Реализация свободна в выборе технологий (React, Vue, native mobile, server-side HTML), но не в определениях — те задаёт спецификация.

LLM в IDF уместен на этапе проектирования (вывод онтологии из описания домена, предложение паттернов, enrichment артефакта) и на этапе кристаллизации (witnesses с reliability: "heuristic"). В рантайме LLM отсутствует: ни одно решение, влияющее на состояние мира или рендер, не зависит от непредсказуемого провайдера.

2. Чем IDF не является​

  • Не no-code / low-code генератор. Формат описывает приложение; инструменты вокруг него (Studio, CLI) помогают автору формализовать онтологию. Кодогенерация целевых артефактов не является частью формата.
  • Не runtime framework в духе React, Angular, Svelte. React — один из возможных хостов для pixel-материализации; хост может быть любым. Сам формат не ограничивает выбор стека.
  • Не data-binding fabric. IDF не связывает DOM-узлы с моделями данных. Artifact — структура слотов, а не directive-дерево; читатель интерпретирует слоты согласно своим конвенциям.
  • Не BaaS и не backend-framework. Сервер референсной реализации — один из возможных хостов для фиксации Φ; спецификация не предписывает конкретную архитектуру сервера.
  • Не UI-toolkit. Адаптеры используют UI-toolkit'ы (Mantine, shadcn/ui, Apple-glass, AntD и другие), но адаптер — это mapping между форматом и toolkit'ом, а не сам toolkit.
  • Не IDE-плагин. Authoring environment — отдельный инструмент исследования формата, опциональный и не являющийся его частью.

3. Манифест и спека​

Два документа описывают один формат в разных регистрах.

Манифест (этот текст) — мотивация и неформальные аксиомы. Адресован людям: авторам, архитекторам, исследователям. Цель — передать почему формат устроен именно так и как читать его тексты.

Спека (docs/spec-v0.1/, запланирована к реализации) — нормативный закон. Адресована реализациям: JSON Schema для artifact / intent / effect / ontology / projection, таблица conformance classes, эталонные test fixtures. Цель — дать однозначное определение того, что означает «говорить на IDF».

Манифест без спеки — философия без нормы. Спека без манифеста — норма без контекста. Оба документа обязательны для зрелого формата.

Честное замечание: спека существует как отдельный проект, в активной разработке. Она пишется по frozen snapshot манифеста, без чтения исходников референсной реализации, — этот принцип изоляции нужен, чтобы спека оставалась нормативным документом, а не зеркалом реализации. Текущий scope — L1 + L2; L3 и L4 резервируются для последующих версий. Раздел VI содержит первичный эскиз conformance-классов; детальная матрица, JSON Schema и эталонные test fixtures живут в отдельном репо.