- executable, type-only, framework reference и deferred edges;
- environment capability sets, resolver conditions и framework execution phases;
- API-safe external packages;
- runtime assembly inputs и создаваемыми API, если проект автоматизирует runtime DAG.
Формат такой конфигурации пока не выбран. Проверка анализирует объявленные boundaries и resolved graphs, а не угадывает сущность только по имени папки.
- другой public path или deep import внутри `api`;
- отсутствие Group `assemblies` или модуля `assemblies/default`;
- прямой дочерний элемент `assemblies` или `adapters` без module boundary;
- нарушение importer matrix ports, factories и concrete adapters;
- достижимость adapter, assembly, framework, SDK, storage, state/query runtime или environment-specific code из `api`;
- запрещённый cross-domain import;
- type-only import не из public facet владельца;
- import framework state, hooks, contexts или components другого домена;
- несовместимую executable reachability под каждым configured resolver condition set;
- runtime- или type-only cycles статического module graph.
Проверка external package reachability использует project allowlist API-safe packages. Решение о том, соответствует ли package критериям API-safe, принимается на review; автоматизация проверяет объявленный label и фактически resolved entries.
Неанализируемые dynamic imports запрещаются или явно allowlist-ятся project policy с target capability set.
## Architecture review
На review определяется:
- представляет ли package одну связную предметную область;
- является ли `api` единственным семантическим шлюзом домена;
- соответствуют ли exports `api` реальным consumer contracts, `api/ports` implementer contracts, а`api/factory` объявленным Domain API factories;
- отличаются ли public models от raw provider DTO там, где это необходимо;
- принадлежат ли operations ровно одному Domain API;
- оправдано ли разделение нескольких Domain API независимой сборкой, trust или consumers;
- описывают ли ports consumer-owned capabilities, а не endpoints конкретного SDK;
- достаточна ли closed failure algebra для выбора domain outcomes;
- преобразуются ли provider и foreign-domain failures в собственные errors;
- является ли каждая production implementation отдельным adapter module;
- не выполняют ли framework bindings предметные external operations в обход API;
- не создаёт ли framework projection параллельную модель;
- определены ли optimistic ordering, versioning и reconciliation модулем `api`;
- представляет ли `default` один реальный baseline capability context;
- оправданы ли дополнительные assemblies реальным отличием graph;
- остаётся ли runtime assembly graph ацикличным;
- создаётся ли только dependency-connected часть production graph;
- полностью ли определены lifecycle и cleanup failure paths;
- соответствует ли каждый API-safe package ограничениям;
- остаются ли Groups без implementation и aggregate API.
## Environment review
Для каждого public entry point рассматриваются реальные executable imports под заявленными conditions. Отдельно проверяются:
- RSC server execution;
- Client Component references;
- server prerender graph Client Components при включённом SSR;
- browser hydration graph Client Components;
- framework-deferred browser effects;
- Server Action references;
- browser, Node.js, edge и worker capabilities;
- conditional exports external packages;
- dynamic imports;
- serialization boundaries.
Название `default`, `rsc`, `server` или `client` не является доказательством совместимости. Tree shaking и runtime branching также не являются доказательством.
## Realtime review
Для каждого realtime port фиксируются:
- correlation scope и ACK semantics;
- ordering и duplicate policy;
- disconnect, timeout и `OUTCOME_UNKNOWN`;
- idempotency и retry;
- reconnect, gap detection и resync;
- cancellation;
- shared connection owner;
- cleanup и запрет callbacks после disposal.
Без этих guarantees adapter нельзя считать проверяемой реализацией port.
## Testing
Domain API проверяется через factory с fake ports. Adapter проверяется contract tests concrete provider. Assembly проверяет production wiring, capabilities, partial construction и cleanup. Framework binding проверяет projection, hydration и lifecycle с fake API.
Import-graph checks не заменяются runtime tests, а API fake не заменяет adapter contract test.
Наличие доменных модулей Level 1 рядом с пакетами Level 2 является завершённым допустимым состоянием. Проверка применяет правила формы отдельно к каждой предметной области и правила Level 2 ко всем статическим связям, пересекающим package boundary.
Переход одного домена завершается, когда его старая module boundary удалена и checker видит только package. Другие домены не входят в критерий формы, но dependency-connected consumers и graph owners входят в change radius.
