style: убрать излишний англицызм

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

@@ -4,21 +4,21 @@
 
 ## Зафиксированные решения
 
-- Domain является сущностью только Level 3; в Level 2 предметная область остаётся одним domain module.
-- Domain root не имеет общего runtime barrel.
-- Framework module называется именем framework и размещается непосредственно в Domain: `domains/auth/react`.
-- Framework module получает готовый API и не выполняет assembly.
-- Runtime-взаимодействие business разных Domains проходит через consumer-owned port и graph owner.
-- Navigation Groups допустимы в `domains`, но не являются частью базовых примеров.
+- Домен является сущностью только Level 3; в Level 2 предметная область остаётся одним доменным модулем.
+- Корень домена не имеет общей точки входа для исполняемого кода.
+- Модуль фреймворка называется его именем и размещается непосредственно в домене: `domains/auth/react`.
+- Модуль фреймворка получает готовый API и не выполняет сборку.
+- Взаимодействие бизнес-логики разных доменов во время выполнения проходит через порт потребителя и владельца графа.
+- Навигационные группы допустимы в `domains`, но не являются частью базовых примеров.
 
-## Failure transport
+## Форма передачи ошибок
 
-Level 3 требует stable domain failure contract, но не навязывает проекту единый transport: exception с domain-specific runtime guard или discriminated `Result`. Нужно проверить, нужна ли общая политика для всех Domain одного приложения и как она влияет на server actions/RPC serialization.
+Level 3 требует устойчивый контракт ошибок домена, но не навязывает единый способ передачи: исключение с проверкой типа во время выполнения или размеченный `Result`. Нужно проверить, нужна ли общая политика для всех доменов одного приложения и как она влияет на серверные действия и сериализацию RPC.
 
-## Reactive state protocol
+## Наблюдение за состоянием
 
-Нужно проверить на реальном SSR/hydration кейсе точную форму framework-neutral observation protocol: initial snapshot, concurrent rendering, invalidation, subscription cleanup и поведение после request boundary. `getSnapshot` и `subscribe` пока являются базовой иллюстрацией, а не обязательной файловой формой.
+На реальном примере SSR и гидратации нужно проверить точную форму независимого от фреймворка интерфейса наблюдения: начальный снимок, параллельный рендеринг, сброс данных, очистку подписки и поведение после завершения запроса. Методы `getSnapshot` и `subscribe` пока служат иллюстрацией, а не обязательной файловой формой.
 
-## Architecture lint
+## Автоматическая проверка архитектуры
 
-Нужно выбрать формат project configuration для автоматической проверки Domain roots, role modules, public entrypoints, environment labels и запрещённых transitive imports. Проверка должна опираться на graph и metadata, а не только на имена папок.
+Нужно выбрать формат конфигурации проекта для автоматической проверки корней доменов, их модулей, публичных точек входа, меток сред и запрещённых транзитивных импортов. Проверка должна опираться на граф и описание структуры, а не только на имена папок.