feat: доменный API

DRAFT/level-2/domains/open-questions.md

@@ -7,46 +7,69 @@
 - Level 1 является общей базой, а Level 2 применяется отдельно к выбранным предметным областям.
 - Доменный модуль Level 1 и доменный пакет Level 2 могут постоянно сосуществовать в одном SLM root.
 - Одна предметная область имеет только одну форму.
-- Корень пакета содержит только metadata, модуль `business` и допустимые Groups и не имеет executable API.
-- `business` может объявлять несколько независимо собираемых Domain API и одну фабрику для каждого API.
-- Публичный API `business` имеет обязательные type-only `business` и runtime `business/factory`, а также необязательный deterministic `business/runtime`.
-- Приложение получает предметную модель, transitions и результаты через Domain API; technical и framework cache могут хранить и проецировать эти значения.
-- Ожидаемые ошибки adapters и других доменов не пересекают API текущего домена в исходной форме.
-- Каждый доменный пакет содержит минимум одну assembly; универсальная изоморфная assembly не обязательна.
-- Assembly может создавать именованный граф нескольких API и не добавляет к ним сценарии.
-- При наличии технических зависимостей Group `adapters` обязательна, а каждая связная production implementation принадлежит adapter-модулю.
-- Runtime cross-domain imports через пакетную границу разрешены только из `business/runtime`; type-only public contracts разрешены и входят в DAG.
-- Framework Group называется по фреймворку и содержит самостоятельные SLM-модули.
-- Cross-domain framework state, hooks, contexts и components не импортируются.
-- Clock, timer, random, ID generator и environment являются явными dependencies business.
-- Assembly без собственного lifecycle-ресурса не обязана возвращать пустой `dispose`.
+- Корень package содержит только metadata, модуль `api` и допустимые Groups и не имеет executable API.
+- Модуль `api` является единственным семантическим шлюзом данных и операций домена.
+- Публичные фасеты разделяют consumer types, implementer ports, factories и optional deterministic runtime.
+- Каждый Domain API имеет одну factory; production factories импортируют только assemblies своего домена.
+- Dependency ports принадлежат `api`, а production adapters являются отдельными modules Group `adapters`.
+- Provider errors проходят через closed port failures и преобразуются в stable domain errors.
+- Каждый package содержит `assemblies/default` для одного baseline production context.
+- Имя `default` не определяет environment или isomorphic compatibility.
+- Дополнительная assembly появляется только для отличающегося graph, dependencies, trust, capabilities или lifecycle.
+- Framework bindings владеют state, cache, reactivity и hydration и не обращаются к предметному external source в обход Domain API.
+- Server и client используют разные API instances и caches; через RSC boundary проходят только serializable values.
+- Realtime transport скрыт adapter, а messages и subscriptions доступны через Domain API.
+- Realtime port объявляет correlation, ACK, ordering, duplicate, reconnect, resync, cancellation и cleanup semantics.
+- Assembly rollback выполняет cleanup собственных resources и полученных adapter lifecycle handles; successful aggregate cleanup идемпотентен и прекращает callbacks.
+- Cross-domain Domain API является отдельной runtime dependency, а не автоматически local port.
+- Runtime assembly graph остаётся ацикличным.
 
-## Владение состоянием
+## Канал ошибок
 
-Нужно подробнее определить создание initial state, применение transitions, persistence и внешний event input. Нормативным уже является то, что предметную модель и переходы определяет `business`, а concrete state manager реализует business-owned port либо framework projection.
+Нужно выбрать project-wide recommendation между exceptions и discriminated `Result`, определить форму cancellation и unexpected failures, а также сериализацию domain errors через RPC и Server Actions.
 
-Отдельно требуется проверить SSR snapshot, hydration, concurrent rendering, reset и поведение после завершения request scope.
+Архитектурная цепочка provider failure → port failure → domain error от выбора канала не зависит.
 
-## Передача ошибок
+## Port semantics
 
-Нужно выбрать общую рекомендацию exception или discriminated `Result`, определить cancellation и unexpected failures, а также сериализацию ошибок через RPC и server actions.
+Нужно определить минимальный machine-readable способ объявлять behavioral guarantees ports: timeout, retry, cancellation, idempotency, ordering, concurrency и subscription cleanup.
 
-Структура публичных фасетов от этого решения больше не зависит: type errors публикуются через `business`, а необходимые runtime codes и guards через опциональный `business/runtime`.
+Не все ports требуют все поля, но существенная для корректности semantics не должна существовать только в комментарии adapter implementation.
 
-## Технические порты
+## Environment metadata
 
-Нужно определить, является ли consumer-owned port обязательной формой каждой технической зависимости и какие behavioral guarantees он описывает: timeout, retry, cancellation, idempotency, ordering, concurrency и subscription cleanup.
+Нужно выбрать формат для capability sets, resolver conditions, executable edges, framework reference edges, dynamic imports и API-safe package declarations.
 
-Cross-domain API dependency уже зафиксирована как отдельный вид зависимости и не зависит от этого решения.
+Особенно требуется проверить Next.js RSC, Server Actions, edge runtime, workers и conditional exports внешних packages.
 
-## Lifecycle сборки
+## Runtime dependency graph
 
-Уже зафиксировано, что явная операция, запускающая ресурс, возвращает cleanup, а assembly с собственным ресурсом предоставляет cleanup handle результата. Ещё нужно определить async cleanup, rollback частичной сборки, repeated disposal, request abort и поведение API после завершения scope.
+Нужно выбрать machine-readable формат assembly inputs и создаваемых API, чтобы автоматически обнаруживать runtime cycles, скрытые static structural ports и неверный cleanup order.
 
-## Cache hydration
+До появления формата runtime graph остаётся обязательной review boundary.
 
-Нужно проверить единый способ разделять framework-neutral cache policy, client hooks, server prefetch и serialization boundary без утечки query-library types в Domain API.
+## Lifecycle
 
-## Автоматическая проверка
+Гарантии rollback, reverse cleanup, idempotence и отсутствия callbacks после disposal зафиксированы. Ещё нужно определить aggregate cleanup errors, retry failed cleanup, request abort, deadline disposal и поведение API после завершения scope.
 
-Нужно выбрать machine-readable формат для форм домена, metadata, модулей, Groups, entry points, environment labels и запрещённых транзитивных импортов.
+## Hydration payload
+
+Нужно выбрать рекомендации по versioning, schema validation, stale persisted cache, partial hydration и защите request-specific или sensitive values.
+
+Hydration payload остаётся framework-owned и не может содержать API instance или mutable client.
+
+## Multiple APIs и shared capabilities
+
+Нужно проверить рекомендуемую форму для нескольких Domain API, которые используют один shared connection, transaction coordinator или framework-neutral operation context, не перенося предметную семантику в adapter или assembly.
+
+Если independent factories не сохраняют atomicity, APIs должны объединяться; точный критерий требует дополнительных примеров.
+
+## Framework-only SDK
+
+Нужно проверить React/Vue SDK, которые предоставляют capability только через Provider, hook или component: payment elements, CAPTCHA, maps и identity widgets.
+
+Зафиксировано, что binding может передать Domain API только opaque operation input и не выполняет предметную provider operation напрямую. Требуются проверочные примеры для `infra` + `ui` + composition.
+
+## Масштаб production graph
+
+Нужно проверить lazy и route-scoped сборку на SLM root с десятками Level 2 packages. Импорт assemblies остаётся side-effect-free, а graph owner создаёт только dependency-connected часть graph; конкретный registry или lazy-loading mechanism пока не нормирован.