Технический манифест
формата описания приложения.

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

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».

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

Честное замечание: спека существует сейчас на уровне архитектурного решения и набросков, но не как написанный артефакт. Написание спеки требует стабильности референсной реализации — зрелости достаточной, чтобы фиксировать аксиомы, а не обсуждать их.

§4Φ — лог событий как единственный источник истины

Φ (phi) — это упорядоченная по времени последовательность эффектов, каждый из которых достиг состояния confirmed. Она одна содержит всё изменение мира приложения.

Каждый эффект — это запись вида:

• α — вид изменения: create, replace, remove, transition, commit
• entity — тип сущности, которую эффект затрагивает
• fields — полезная нагрузка (значения полей)
• context — метаданные: кто инициировал, к какой сессии относится, какая степень необратимости, ссылки на другие эффекты

Мир не хранится отдельно. Состояние любой сущности в любой момент — результат fold(Φ) (см. §11), применённого к эффектам, видимым к этому моменту. Это свойство даёт три следствия, которые проходят через весь формат:

1. Audit trail бесплатный: каждое изменение в мире имеет свидетеля в Φ. Нет in-place мутаций, которые обошли бы журнал.
2. Rebuild from scratch — первоклассная операция. Тесты, дебаг, миграция — всё это частные случаи перевычисления мира от Φ.
3. Причинность сохраняется: rejected эффекты тоже остаются в журнале (в отдельной зоне), чтобы можно было понять, что именно было отвергнуто и почему.

Жизненный цикл эффекта: proposed → { confirmed | rejected }. Переход — отдельный шаг валидации, в котором проверяются инварианты онтологии, препятствия типа irreversibility и условия намерения.

§5Δ — черновики, session-scoped namespace

Δ (delta) — это пространство черновиков: эффектов, инициированных, но не достигших статуса confirmed. Черновики видны только инициатору и живут до момента commit, cancel или истечения сессии.

Структурная функция Δ в формате — позволить автору намерения накапливать состояние до решения его зафиксировать. Форма-wizard с четырьмя шагами — череда черновиков, где каждый шаг добавляет поля; финальный шаг превращает accumulated draft в confirmed effect.

Промоция Δ → Φ происходит атомарно при подтверждении намерения. Rejected черновики уничтожаются (не становятся частью Φ, не остаются в rejected-зоне — это чистый рабочий процесс автора, не свидетельство в мире).

Множественные черновики одного инициатора могут существовать параллельно: пользователь может работать одновременно над несколькими намерениями.

§6Intent — конструктивные частицы

Intent — это декларативное описание возможности изменить мир, которая может быть предложена viewer'у.

Намерение — не функция и не handler. Оно — запись формата:

• id — стабильный идентификатор
• ownerRole — какая роль авторизована его инициировать
• requiredFields — какие поля должны быть заполнены до подтверждения
• conditions — предикаты над миром, которые должны выполняться
• effects — список эффектов, которые будут эмитены при подтверждении

Пять первичных видов намерений (α / β / χ / τ / ω), соответствующих пяти видам эффектов: создание, замена, удаление, переход состояния, commit workflow. Шестой вид — системные намерения: schedule_timer, revoke_timer — конструкты темпорального слоя.

Generic effect handler формата механически применяет объявленные effects к Φ. Это свойство — ключевое: намерения не несут императивный код. Domain-автор описывает, что должно произойти; движок гарантирует, как это произойдёт.

§7Effect — атомы изменения мира

Эффект — квант изменения: минимальная единица, которая может быть записана в Φ.

{ α, entity, fields, context }

Поле α принимает одно из пяти значений:

• create — добавить новую сущность
• replace — заменить поля существующей сущности
• remove — удалить сущность (с ограничением irreversibility)
• transition — изменить состояние workflow'а
• commit — зафиксировать завершение сложной частицы (wizard, batch)

Поле context несёт метаданные, важные для валидации и интерпретации:

• __irr: { point, at, reason } — степень необратимости: point = "high" блокирует последующие remove после at
• ссылки на инициирующее намерение, инициатора, session-id
• external refs — если эффект отражает вовне-мировое событие

§8Ontology — тип данных домена

Онтология — центральный объект формата. Она определяет, что такое «домен»: какие сущности существуют, какие роли ими манипулируют, какие инварианты должны выполняться, какие правила автоматики движок исполняет.

§8.1Entities

Сущности — типы данных домена. Каждая имеет:

• fields — типизированные поля с read/write matrix по ролям
• ownerField — поле, указывающее single-owner (foreign key на роль)
• kind — таксономический маркер: internal (default), reference (без owner), assignment (bridge для m2m)

Приоритет row-filter: role.scope > entity.kind:"reference" > entity.ownerField > none.

§8.2Roles и base-таксономия

Роли — это viewer-типы. Каждая роль имеет:

• base — семантическая таксономия: owner | viewer | agent | observer | admin
• visibleFields — какие поля каждой сущности она видит
• canExecute — какие намерения она может инициировать
• scope — декларативное m2m-присоединение через bridge-сущность

Base-таксономия не заменяет доменные имена; она даёт cross-domain инструментам возможность узнавать структурный паттерн: «все agent-роли обязаны иметь preapproval», «observer-роли не могут эмитить α-эффекты», «admin-роли видят все записи независимо от ownerField».

Базы устроены как открытое множество прецедентов, не closed enum: пятый класс admin появился post-v2.0 после стресс-теста на library-домене.

§8.3Invariants — ∀-свойства

Инварианты — декларативные предикаты, которые должны выполняться для состояния мира всегда. Пять видов:

• role-capability — какие роли могут инициировать какие намерения
• referential — referential integrity (foreign keys)
• transition — допустимые переходы workflow (state machine)
• cardinality — N-to-M кардинальности
• aggregate — свойства агрегатов (sum(portfolio.positions.weight) = 1.0)

Инварианты проверяются при каждом confirm effect. Нарушение блокирует эффект и каскадно отклоняет зависимые.

§8.4Rules — Reactive Rules Engine

Правила — декларативные event-condition-action автоматы. Четыре расширения:

• aggregation: счётчик per-user, срабатывает на каждое N-е событие
• threshold: предикат над последними N записями (lookback window)
• schedule: темпоральный триггер
• condition: JS-выражение (whitelisted Math)

§8.5Scheduler — темпоральный слой

Расписание — частный случай rule:

rule.schedule = { after: <duration> }
         | { at: <ISO timestamp> }
         | { after: ..., revokeOn: <effect patterns> }

Движок поддерживает priority-queue таймеров. Таймеры — обычные эффекты (τ=scheduled_timer) в Φ. Системные намерения: schedule_timer(afterMs | atISO, target, revokeOn?), revoke_timer(timerId).

§8.6Field roles — семантические типы

Поле сущности имеет тип (string, number, enum, ...) и, опционально, семантическую роль:

• pure-data: money, percentage, trend, ticker
• spatial: coordinate, address, zone
• temporal: datetime, duration

Семантические роли — advisory hints для читателей формата. Формат гарантирует, что роль будет прослежена в артефакт; качество рендера — свойство читателя.

§9Projection — авторский контракт

Projection — декларация автора о том, какие намерения и сущности образуют один «экран», «диалог», «страницу». Она содержит:

• список намерений, которые должны быть доступны в этой проекции
• предпочтительный архетип (catalog, detail, form, feed, canvas, dashboard, wizard) или auto
• preference по паттернам Pattern Bank'а: patterns: { enabled: [...], disabled: [...] }
• опциональный slot-override для конкретных мест в артефакте

Projection — это input для кристаллизации; artifact — output. Автор влияет на результат через два механизма:

• Projection.patterns — preference, модификатор входа. Артефакт остаётся перегенерируемым из (intents, ontology, projection, patterns, features).
• Slot-override — freezing output. Автор фиксирует конкретный слот, bypass'а кристаллизацию. Потеря: артефакт больше не чистая функция от входа.

Preference сохраняет инвариант «артефакт = f(input)»; slot-override жертвует им ради локального контроля. Рекомендация формата: preference first, slot-override только когда preference принципиально не выражает нужное поведение.

§10Artifact — кристаллизованный результат

Артефакт v2 — это тип данных, не результат рендеринга.

Структура артефакта:

• archetype — один из семи: feed, catalog, detail, form, canvas, dashboard, wizard
• slots — именованные контейнеры содержимого (header, body, footer, toolbar, sidebar, ...)
• witnesses — structured findings о свойствах артефакта
• shape — деривационный слой над архетипом (timeline, directory, default)
• pattern annotations — матченные паттерны Pattern Bank'а

Witnesses — свидетельства свойств артефакта. Три основных basis:

• heuristic — вывод через эвристику; reliability: "heuristic", требует promotion через анкеринг
• pattern-bank — formal match паттерна банка; reliability: "rule-based", детерминированный
• anchored — constructive proof через witness-of-proof. Самый сильный класс; anchoring promotion writer — открытая epistemic задача

Артефакт не рендерится напрямую. Его читают разные материализации: pixel-рендерер собирает DOM, voice-материализатор строит speech-script, agent-API сериализует в JSON-schema, document-генератор строит HTML-граф.

Семь структурных архетипов описывают скелет артефакта; пять behavioral паттернов (monitoring, triage, execution, exploration, configuration) — перпендикулярны архетипу и описывают поведение.

§11fold — мир как функция от Φ

fold(Φ) → world — чистая операция reduce, применяющая эффекты журнала к начальному пустому состоянию в порядке их времени.

Детерминизм — жёсткое требование: один и тот же Φ даёт одно и то же состояние мира. Это следует из трёх свойств:

1. α-квантование: каждый эффект описывает минимальный шаг. Последствия эффекта локализованы.
2. Порядок устойчив: эффекты в Φ упорядочены по времени, fold применяет их строго в этом порядке.
3. Без сайд-эффектов в fold: fold — функция над данными, не читает внешние источники.

Из детерминизма следует, что rebuild from scratch — первоклассная операция.

Производные от fold:

• foldFiltered(Φ, predicate) — пересчёт мира только по релевантным эффектам
• foldView(Φ, viewerRole, ontology) — композиция fold и viewer-scoping

§12Crystallization — артефакт как чистая функция

Кристаллизация — процедура, превращающая набор намерений и онтологию в артефакт. Её сигнатура:

crystallize(intents, ontology, projection, patternBank, features) → artifact

Все пять аргументов — input; артефакт — output. Никаких скрытых состояний, LLM-провайдеров или сетевых обращений.

Процедура состоит из шести фаз:

1. deriveProjections — выводит скелеты проекций из (intents × ontology) по правилам R1–R8
2. mergeProjections — shallow-merge авторских projection поверх derived-скелетов
3. assignToSlots — распределяет намерения и данные по слотам согласно архетипу
4. matchPatterns — применяет Pattern Bank в matching-режиме; сматченный паттерн становится witness'ом
5. applyStructuralPatterns — для паттернов с structure.apply прогоняет apply-функцию
6. wrapByConfirmation — оборачивает намерения в control-архетипы

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

§13Pattern Bank — декларативные правила деривации

Pattern Bank — формализованный реестр правил, которые угадывают структуру артефакта из конфигурации входа. Каждый паттерн — запись формата:

{
  id: "subcollections",
  archetype: "detail",
  trigger: { match(projection, ontology, intents) → bool, ... },
  structure: {
    rationale: "...",
    apply?: (slots, context) → mutated slots
  },
  falsification: { shouldMatch: [...], shouldNotMatch: [...] }
}

Три формы паттерна:

• Matching-only — паттерн имеет trigger и rationale, но не apply. Роль: аннотация.
• Structure.apply — паттерн имеет чистую функцию apply(slots, context) → slots, которая обогащает артефакт.
• Rationale-only — паттерн имеет только объяснительный narrative.

Behavioral vs structural: поведение (monitoring, triage, execution, exploration, configuration) и структура (subcollections, grid-card-layout, hero-create, ...) — ортогональны.

Falsification framework — обязательная часть каждого стабильного паттерна. Декларация shouldMatch фиксирует примеры, где паттерн должен сработать; shouldNotMatch — где не должен.

Witnesses с basis: "pattern-bank" имеют reliability: "rule-based" — самый сильный класс после anchored.

§14Viewer-scoping — мир и артефакт как функции viewer'а

Один и тот же мир выглядит по-разному для разных ролей — не потому, что рендерер решает что-то скрыть, а потому, что viewerWorld — это отдельный тип данных.

Функция filterWorldForRole(world, viewer, ontology) → viewerWorld применяет row-filter по приоритету:

1. role.scope — m2m через bridge-сущность
2. entity.kind: "reference" — справочные сущности видны всем
3. entity.ownerField — single-owner semantics
4. none — если ни одного из правил не сработало, сущность не видна (privacy by default)

Base-таксономия роли усиливает viewer-scoping:

• owner — видит свои сущности, может инициировать все namespace намерений
• viewer — видит ограниченное подмножество (read-mostly)
• agent — видит то же, что owner, но каждое намерение проходит через preapproval guard
• observer — видит read-only view без привилегий

Материализации (pixel, voice, agent API, document) все используют один и тот же filterWorldForRole. Viewer-scoping — единый механизм безопасности формата.

§15Pixels — runtime UI

Pixel-материализация — рендеринг артефакта в DOM. Читатель состоит из трёх слоёв:

• Renderer — интерпретирует структуру артефакта и строит дерево абстрактных UI-узлов
• Adapter — mapping между абстрактными узлами и конкретным UI-toolkit'ом (pluggable)
• Token Bridge — канонический contract CSS-переменных между адаптером и доменным кодом

Capability surface — декларативный список поддерживаемых адаптером primitive'ов:

adapter.capabilities = {
  primitive: {
    chart:     { chartTypes: ["line", "pie"] },
    map:       false,
    statistic: true,
    sparkline: true
  }
}

Renderer консультируется с capability при выборе primitive'а. Mismatch → console.warn + fallback. Unknown capability — assume supported.

Token Bridge — формальный contract. Адаптер обязан предоставить canonical CSS-переменные; domain-специфичный код пишет только в canonical переменные, адаптер мапит их в свои значения.

§16Voice — speech-script

Voice-материализация превращает проекцию в структурированный speech-script:

materializeAsVoice(projection, world, viewer) → turns[]

Turn — речевая единица:

{ role: "system" | "assistant" | "prompts", text, items? }

Три формата вывода:

• json — для voice-agent (Claude Voice, OpenAI realtime)
• SSML — XML для TTS-движков
• plain — для debug или IVR

Brevity-правила:

• Catalog с более чем тремя элементами — озвучиваются top-3 с «и ещё N»
• Money читается человеческим языком: 2500000 RUB → «два с половиной миллиона рублей»
• Percentage и trend формируются как числительные, не символы

Voice использует тот же filterWorldForRole, что pixel и agent API. Viewer-scoping транзитивен.

§17Agent API — JSON + exec

Agent API превращает формат в schema + RPC для внешних LLM-агентов. Три endpoint'а:

• GET /agent/:domain/schema?as=<role> — JSON-schema намерений
• GET /agent/:domain/world?as=<role> — viewer-scoped world snapshot
• POST /agent/:domain/exec?as=<role> — подтверждение намерения с payload

Preapproval guard — декларативный лимитирующий слой для agent-base ролей:

role.agent.preapproval = {
  createTrade: { active: true, maxAmount: 100000, dailySum: 500000 }
  rebalance:   { notExpired: true, csvInclude: ["AAPL","MSFT"] }
}

Пять типов предикатов: active, notExpired, maxAmount, csvInclude, dailySum.

Guard проверяется перед любыми invariants онтологии. Agent API — это не отдельная материализация в смысле «альтернативного вида UI»; это машинный интерфейс формата, равноправный с пиксельным.

§18Document — HTML / JSON граф

Document-материализация превращает проекцию в structured document-граф:

materializeAsDocument(projection, world, viewer) → documentGraph

Document-граф — дерево узлов:

• Sections — заголовки, тело, подсекции
• Tables — коллекции с колонками (catalog-архетип)
• Fields — name-value пары с semantic type
• Badges — маркеры статуса, irreversibility, ролей

Два формата вывода: HTML (server-side, для браузера / печати), JSON (для индексации, экспорта, архива).

Document больше не «альтернативная материализация» — это четвёртый равноправный читатель. Формат делает один и тот же контент доступным пользователю (pixel), голосом (voice), агенту (JSON API) и документом (HTML/JSON).

§19Где уместен LLM

IDF — формат, в котором LLM отсутствует в рантайме. Это означает: ни одно решение, влияющее на состояние мира или на рендер артефакта, не зависит от непредсказуемого провайдера. Детерминизм формата не соседствует с LLM; он его исключает.

Это не означает, что LLM бесполезен. Напротив, он уместен в трёх местах формата — все на этапе проектирования:

(а) Вывод онтологии из описания домена

Автор описывает домен текстом. LLM превращает описание в draft онтологии: сущности, поля с типами и read/write matrix, роли, начальные намерения. Draft — не истина; автор подтверждает, корректирует или отвергает.

(б) Crystallize enrichment

Артефакт после кристаллизации — структура слотов и контролов. Labels, placeholder'ы, iconHints, explanation-теггинги — это натурально-языковые строки, которые LLM может предложить. Enrichment — это witness-of-heuristic: reliability "heuristic", caveat «это предположение, требующее подтверждения».

(в) Pattern suggestion

Pattern Bank расширяется постепенно. LLM-researcher pipeline просматривает живые приложения, находит повторяющиеся структурные паттерны, предлагает их как candidate-паттерны. Candidate становится stable после human review и добавления falsification-fixtures.

Что исключено из LLM:

• Runtime UI — рендер артефакта в DOM происходит детерминированно
• Execute — валидация и применение намерений не обращаются к LLM
• Materialize — voice, agent API, document не генерируются LLM
• Анкеринг без witness-of-proof — переход witness'а к более сильному классу требует декларативного доказательства

Формат проектирует так, чтобы LLM можно было заменить любой другой design-time эвристикой (grep+линтеры, rule-based recommendation, human-only) без изменения формата и его гарантий.

§20Authored vs derived

Каждый элемент артефакта имеет происхождение: он либо authored (автор проекции зафиксировал его), либо derived (движок вывел его из намерений и онтологии).

Это различие — первоклассное свойство артефакта. Его можно прочесть в artifact.witnesses[]: derived-элементы несут witness с соответствующим basis (pattern-bank, heuristic), authored-элементы — witness с basis authored или отсутствуют.

Формат даёт автору два различающихся механизма влияния на derived-часть:

• Preference (input modifier): projection.patterns = { enabled: [...], disabled: [...] }. Артефакт остаётся чистой функцией.
• Slot-override (output freeze): авторская projection.slots явно переопределяет слот артефакта. Свойство «артефакт = f(input)» для этой части теряется.

Формат не запрещает slot-override, но рекомендует preference как первый выбор. Если slot-override становится распространённым — это сигнал расширить Pattern Bank или онтологию.

Authored vs derived — не дихотомия «мой код vs движка». Это epistemological различие: derived-часть имеет формальное происхождение, authored — декларативное решение автора.

§21Authoring environment

Studio — отдельный инструмент исследования формата: визуализация онтологии как графа, Pattern Inspector для prototype-preview кристаллизации, viewer/role switching, Φ-playback. Формально Studio не является частью формата и не требуется для конформной реализации.

Важно, что Studio не участвует в рантайме. Если автор использует Studio при проектировании и потом поставляет домен в production, никакой элемент рантайма не знает о существовании Studio.

Это следует из строгого разделения:

• Формат — описание (онтология, намерения, проекции, Pattern Bank)
• Реализация — читатели формата (adapter, voice, agent, document)
• Studio — инструмент работы с описанием (design-time)

Studio может быть реализована разными способами и командами — на React, как CLI, как LSP-plugin. Это также не ограничивает формат.

Наличие или отсутствие Studio — не аксиома формата, но её возможность — важный качественный тест «формат достаточно ясен, чтобы быть auditable'ным».

§22Классы L1–L4

Формат определяет четыре класса конформности, каждый — subset предыдущего.

L1 — Minimum

Реализация умеет: парсить онтологию, парсить namespace намерений, складывать Φ (append-only log), выполнять fold(Φ) → world. L1-реализация может не иметь UI, не иметь кристаллизации, не иметь материализаций.

L2 — Crystallize

L1 плюс: базовая кристаллизация, хотя бы один архетип (минимум — detail), assignToSlots без Pattern Bank, mergeProjections для авторских override'ов. L2 достаточна для реализаций, которые работают только с machine-interface: agent API, document generation.

L3 — Four materializations

L2 плюс: Pattern Bank matching (без structure.apply), все четыре материализации (pixel, voice, agent API, document) с единым viewer-scoping, минимум два архетипа.

L4 — Full

L3 плюс: Pattern Bank с structure.apply, все пять видов инвариантов, irreversibility с integrity-правилом, темпоральный scheduler, custom canvas / primitive extension points.

Внедрение формата начинается с L1 и может остановиться на L2 или L3 для специфичных задач. Переход L3 → L4 не является обязательным.

§23Инварианты формата

Четыре аксиомы, которые конформная реализация обязана гарантировать:

1. Детерминизм кристаллизации

crystallize(intents, ontology, projection, patternBank, features) — чистая функция. Два вызова с идентичным входом возвращают идентичный артефакт. Никаких скрытых состояний, временны́х зависимостей, LLM-побочных эффектов.

2. Viewer-scoping — тип данных, не фильтр

viewerWorld = filterWorldForRole(world, viewer, ontology). Это — тип данных для конкретного viewer'а, не постобработочный фильтр render'а. Любая материализация читает viewerWorld, не world.

3. Irreversibility — свойство эффекта, не процесса

Эффект с context.__irr = { point: "high", at: <past ISO> } не может быть отменён через α: "remove" на целевой сущности. α: "replace" (forward correction) разрешён всегда.

4. Audit trail через Φ

Любое изменение мира происходит через confirmed effect в Φ. Мир не редактируется in-place. Это означает, что история мира полная — каждое изменение имеет свидетеля.

Эти четыре инварианта не обсуждаются. Любая реализация, нарушающая один из них, не является конформной — вне зависимости от класса L1–L4.

§24Что формат не решает

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

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

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

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

• Analytical UI. Чарты, heatmap'ы, 2D-редакторы, timeline-визуализации, map-canvas'ы — не кристаллизуются автоматически. Сложная аналитика требует authored custom canvas.
• Capability mismatch. Добавление нового primitive kind без обновления адаптера производит fallback (SVG/text), не ошибку.

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

• Cluster-friendly scheduler. Темпоральный слой — single-leader in-memory TimerQueue.
• Supply chain и dependency management. Формат не описывает, как загружать домены, apply миграции, обрабатывать breaking changes онтологии.
• Backup, replication, disaster recovery. Φ — append-only log, легко backup'ируется, но конкретные BCDR-стратегии — вне формата.

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

• PDF / DOCX output. DocumentMaterializer даёт HTML/JSON граф; PDF/DOCX требуют server-side rendering пайплайна, который не формализован.
• Второй reference implementation. Единственная существующая референсная реализация — React/Node. Без второй реализации формат не получил структурного стресс-теста на связь с React-specifics.

Epistemic границы

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

§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.

§26Направления развития формата

Формат в текущем виде — не финальный. Ниже — направления развития, не roadmap. Они могут развиваться параллельно и независимо; их последовательность определяется исследовательскими результатами, а не календарём.

Нормативная спека docs/spec-v0.1/

JSON Schema для artifact, intent, effect, ontology, projection; таблица conformance classes с детальной матрицей L1–L4; набор эталонных test fixtures. Это отдельный проект, не минорная версия манифеста.

Второй reference implementation

Vue, Svelte, native mobile, или server-side-first (Phoenix LiveView, Rails + Turbo). Вторая реализация — структурный стресс-тест формата на decoupling от React.

Pattern Bank expansion

От тринадцати к пятидесяти и более stable-паттернов через Claude Researcher pipeline. Механизм promotion candidate → stable через human review + falsification-fixtures. Формализация anti/ — явно запрещённых паттернов.

Новые материализации

Текущие четыре — достаточны, но не исчерпывают пространство целевых сред:

• Print — PDF / DOCX через server-side document-renderer
• Embed — iframe-совместимая materialization для встраивания в third-party приложения
• AR / XR — spatial layout читатель артефакта для голографических / расширенных сред
• Email — structure-граф в HTML-email, с degradation для legacy клиентов

Каждая новая материализация — реализация читателя; формат не меняется.

Distributed scheduler

Темпоральный слой как replicated state machine: unblocks enterprise deployments, multi-region failover, consistent timer guarantees.

Authoring loop closure

Anchoring promotion writer + counterexample-search — замкнуть epistemic контур. Механизм, позволяющий witness-of-heuristic превращаться в witness-of-proof через automated counterexample-search или declarative human confirmation.

Polymorphic entities

Union-типы в entity.kind — закрытие семантической границы, упомянутой в §24.

Эти направления не образуют линейный roadmap. Они — стороны формата, каждая из которых может развиваться независимо. Выбор приоритетов определяется тем, какое направление принесёт наибольший валидационный сигнал: какое сдвинет уверенность в том, что IDF — достаточная абстракция для описания приложений.