Часть VIII. Перспектива
26. Направления развития формата
Формат в текущем виде — не финальный. Ниже — направления развития, не roadmap. Они могут развиваться параллельно и независимо; их последовательность определяется исследовательскими результатами, а не календарём.
Нормативная спека. JSON Schema для artifact, intent, effect, ontology, projection; таблица conformance classes с детальной матрицей L1–L4; набор эталонных test fixtures. Это отдельный проект, не минорная версия манифеста. Спека в активной разработке; её текущий scope — L1 + L2, с резервированием L3 + L4 под последующие версии. Расширение до L4 — вопрос зрелости референсной реализации и обратной связи с cross-stack реализациями.
Cross-stack конформанс. Независимые реализации формата на альтернативных стеках (systems-языки, native mobile, server-side-first вроде Phoenix LiveView или Rails + Turbo) — структурный стресс-тест на decoupling от любого конкретного языка. Реализации пишутся в изоляции: единственный input — нормативная спека, чтение исходников референсной реализации запрещено. Это принцип честного эксперимента: если реализация успешно проходит conformance по спеке без чтения кода — формат decoupled. Если нет — конкретное расхождение становится баг-репортом к спеке. Расширение от L1 + L2 до L3 + L4 в других стеках — открытое направление.
Pattern Bank expansion. Масштабирование банка stable-паттернов через автоматизированный research pipeline: извлечение кандидатов из реальных приложений, формулирование trigger/rationale, генерация falsification-fixtures. Механизм promotion candidate → stable через human review. Формализация anti/ — явно запрещённых паттернов (anti-patterns), которые движок распознаёт и предупреждает о применении.
Новые материализации. Текущие четыре — достаточны, но не исчерпывают пространство целевых сред:
- Print — PDF / DOCX через server-side document-renderer
- Embed — iframe-совместимая materialization для встраивания в third-party приложения
- AR / XR — spatial layout читатель артефакта для голографических / расширенных сред
- Email — structure-граф в HTML-email, с degradation для legacy клиентов
Каждая новая материализация — реализация читателя; формат не меняется.
Intent salience и spec-debt. Детерминизм кристаллизации (§12) — это не то же самое, что её семантическая устойчивость. Когда M намерений конкурируют за слот ёмкости N < M, формально корректный алгоритм без ranking-contract'а выбирает первые N по алфавиту id — результат повторяемый, но не осмысленный. Intent salience формализована как первоклассное свойство: автор декларирует intent.salience (explicit ординальная метка или число), движок сортирует кандидатов через tie-break ladder: salience desc → declarationOrder asc → alphabetical. declarationOrder — authorial signal из Object.entries(INTENTS) index («автор кладёт важнее первым»). Недостающие salience выводятся из particles.effects по правилам (creates-main → primary, phase-transition → secondary, remove-main → tertiary). Случаи, где tiebreak всё же оказывается алфавитным, фиксируются как witness'ы с basis alphabetical-fallback — spec-debt метрика, практически unreachable в single-domain контексте. Witness basis declaration-order — норма для equal-salience групп, signals authorial ordering. Состояние 2026-04-20: 0 alphabetical-fallback witnesses в 10 доменах prototype'а. Открытое направление — numeric salience для fine-ranking overlapping primaries + promotion heuristics для computed defaults.
Distributed scheduler. Темпоральный слой как replicated state machine: unblocks enterprise deployments, multi-region failover, consistent timer guarantees. Требует изменения контракта TimerQueue без изменения формата user-visible API.
Authoring loop closure. Anchoring promotion writer + counterexample-search — замкнуть epistemic контур, описанный в главах 10 (witnesses) и 19 (где уместен LLM). Механизм, позволяющий witness-of-heuristic превращаться в witness-of-proof через automated counterexample-search или declarative human confirmation.
Polymorphic entities. Union-типы в entity.kind — закрытие семантической границы, упомянутой в 24.
Эти направления не образуют линейный roadmap. Они — стороны формата, каждая из которых может развиваться независимо. Выбор приоритетов определяется тем, какое направление принесёт наибольший валидационный сигнал: какое сдвинет уверенность в том, что IDF — достаточная абстракция для описания приложений.
Нормативная спецификация (docs/spec-v0.1/) и текущий имплементационный статус (implementation-status.md) — отдельные документы. Манифест остаётся мотивацией и неформальным определением формата.