@opetope/runtime 0.1.0

package/docs/spec.ru.md

@@ -0,0 +1,884 @@
+# Opetope — спецификация фреймворка
+
+Нормативная спецификация фреймворка композиции фич Opetope: `@opetope/core`, `@opetope/runtime`, `@opetope/react`.
+Всё ниже описывает фреймворк таким, какой он есть. Там, где правило иначе выглядело бы произвольным, один указатель
+в конце называет решение, которое его зафиксировало.
+
+---
+
+## 1. Цель и принципы
+
+Opetope композирует фичи: граф фич с явными зависимостями, владеемое состояние с точным lifecycle, типизированные
+вызовы с политиками, точки расширения с cardinality и React-слой без service locator. Слоты и явный граф образуют
+небольшой авторский словарь. Runtime владеет lifecycle, подписками и гардами вызовов; наблюдаемые данные следуют
+времени жизни своих читателей без самодельных `useEffect`.
+
+Явный non-goal: SSR, hydration и персистентность. Данные живут в моделях и ресурсах экземпляра и не сериализуются —
+ни снимка состояния для сервера, ни восстановления из него фреймворк не предлагает; пересмотр этой границы это
+отдельный RFC (см. decisions.md, D155).
+
+Всё остальное выведено из этих принципов.
+
+1. **Один семантический факт объявляется один раз.** Механическое выводится нормализацией и проверяется валидацией.
+2. **Одно понятие, одно слово, на всех стадиях.** Модель объявляется `defineModel`, создаётся `model(...)`, читается
+   `useModel`.
+3. **Автор фичи видит только авторский словарь.** Kernel, машина экземпляров, IR и authority живут в `internal` и
+   доступны реализации фреймворка и интеграции хоста. Потолок — 40 value-экспортов и 60 типов на трёх безопасных входах.
+4. **Обязателен только `id`.** Секции появляются по потребности, пустых секций автор не пишет.
+5. **Слои разделены физически.** UI фичи импортирует только собственные контракты фичи. Модель не знает о фиче,
+   портах и импортах: свои зависимости она объявляет собственным интерфейсом, фича их подставляет. Чужая фича
+   доступна только через `imports` или `requires`.
+6. **Sugar lower-ится в один IR.** Любая короткая форма имеет compile-тест эквивалентности длинной и не создаёт
+   второго runtime-пути.
+7. **Фреймворк независим от хоста.** Адаптеры приложения зависят от `@opetope/*`; пакеты фреймворка не зависят от
+   кода приложения. Сервисы хоста входят через явные контракты.
+
+---
+
+## 2. Как выглядит фича
+
+Фича это один `defineFeature` с семью секциями. Пример на двух фичах: `catalog.catalog` владеет каталогом активов и
+отдаёт порт «разрешить актив», `checkout.createForm` требует его и показывает форму.
+
+```ts
+// features/catalog/integration/platform/catalog/feature.ts
+const catalogCatalogFeature = defineFeature({
+  id: 'catalog.catalog',
+  imports: { platform: catalogHost }, // defineHostContract<CatalogHost>('catalog.catalog.platform')
+  own: ({ imports, resource, calls }) => ({
+    // async-материализация с retention; источник и селектор цели позиционные
+    catalog: resource(imports.platform, source => source.target, {
+      key: target => target,
+      load: (_target, { signal, source }) => source.load(signal),
+      retention: scoped({ capacity: 1 }),
+    }),
+    ...calls(imports.platform, ['resolveItem']), // методы хоста как Call, один к одному
+  }),
+  exports: ({ own }) => ({ resolveItem: own.resolveItem }), // для фич, импортирующих это определение
+  provides: ({ port, own }) => ({
+    resolve: port(resolveItemPort, own.resolveItem), // порт для тех, кто его требует
+  }),
+});
+```
+
+```ts
+// features/checkout/models/orderModel.ts — не знает о фиче
+type OrderPlatform = {
+  resolveItem(input: { itemId: string }, signal: AbortSignal): Promise<Item | null>;
+  submit(intent: Intent, signal: AbortSignal): Promise<Receipt>;
+};
+
+export const OrderModel = defineModel<{
+  amount: Readable<number>;
+  item: Readable<Item | null>;
+  resolveItem: Call<{ itemId: string }, Item | null>;
+  submit: Call<Intent, Receipt>;
+}>('checkout.order');
+
+export const createOrderModel = (ctx: ModelContext, platform: OrderPlatform): ModelOf<typeof OrderModel> => {
+  const amount = ctx.state(0); // владеемое состояние; запись только через ctx.update
+  const item = ctx.state<Item | null>(null);
+  // метод зависимости формы `(input, signal)` становится `Call` одной строкой
+  const { resolveItem } = ctx.calls(platform, ['resolveItem']);
+  const submit = ctx.call({
+    run: async (intent: Intent, { invoke, signal }) => {
+      const resolved = await invoke(resolveItem, { itemId: intent.itemId }); // вызов через контекст
+      ctx.update(item, resolved);
+      return platform.submit({ ...intent, precision: resolved?.precision }, signal);
+    },
+  });
+
+  return { amount, item, resolveItem, submit };
+};
+```
+
+```tsx
+// features/checkout/integration/platform/createForm/feature.tsx — единственное место, знающее обе стороны
+const createFormFeature = defineFeature({
+  id: 'checkout.createForm',
+  imports: { platform: createFormHost, catalog: catalogCatalogFeature }, // хост через контракт, фича через определение
+  requires: { resolveItem: resolveItemPort }, // порт; провайдера выберет приложение
+  own: ({ model, imports, requires }) => ({
+    // запись зависимостей разрешает refs: фабрика получает материализованное значение хоста
+    order: model(OrderModel, { platform: imports.platform }, (ctx, { platform }) => createOrderModel(ctx, platform)),
+    lookup: requires.resolveItem, // в `own` порт остаётся ref-ом
+  }),
+  // здесь `own` уже материализован: и порт, и поле модели пришли живыми `Call`
+  exports: ({ own }) => ({ lookup: own.lookup, submit: own.order.submit }),
+  provides: ({ slot, pipe }) => ({
+    // вклад это значение, фабрика экземпляра или дескриптор pipe; `priority` и `when` в опциях третьим
+    content: slot(orderFormContentSlot, ({ exports, model }) => ({
+      Component: CreateForm,
+      // UI-модель вклада: создаётся на каждое монтирование и видит `props` именно этого монтирования
+      models: [
+        model(OrderActions, (ctx, props: Readable<OrderFormProps>) => ({
+          submit: ctx.call({
+            run: (amount: number, { invoke }) => invoke(exports.submit, { amount, itemId: props.getSnapshot().itemId }),
+          }),
+        })),
+      ],
+      props: ({ itemId }: OrderFormProps) => ({ itemId }), // адаптер пропсов слота под пропсы компонента
+    })),
+    toolbar: slot(
+      orderHeaderToolbar,
+      { Component: SubmitToolbarButton },
+      // предикат этого экземпляра: `read` записывает, от чего зависит ответ, а `false` удерживает вклад
+      { priority: 10, when: ({ imports, read }) => read(imports.platform.submitAllowed) },
+    ),
+    // pipe объявляет обработчик дескриптором: `fold` выполняется на свертке, с контекстом этого экземпляра
+    amount: pipe(orderAmountFormatter, { fold: value => value.trim() }),
+  }),
+  when: [authorized], // фича живёт, пока условие истинно; без `when` живёт с приложением
+});
+```
+
+```tsx
+// features/checkout/ui/createForm/contracts.ts — контракты UI
+export const orderFormContentSlot = defineSlot<OrderFormProps>({ id: 'checkout.createForm.content' });
+
+export const OrderActions = defineModel<{ submit: Call<number, Receipt> }>('checkout.createForm.actions');
+
+// features/checkout/ui/createForm/CreateForm.tsx — компонент импортирует только контракты своей фичи
+export const CreateForm = requiresModels([OrderActions])(({ itemId }: { readonly itemId: string }) => {
+  const order = useModel(OrderModel); // модель `own`: её служит сам вклад
+  const actions = useModel(OrderActions); // UI-модель вклада: она перечислена в `requiresModels`
+  const amount = useReadable(order.amount);
+  const { run, inFlight, result, lastError } = useCommand(actions.submit);
+
+  return <Form amount={amount} itemId={itemId} busy={inFlight} error={lastError} receipt={result} onSubmit={run} />;
+});
+```
+
+Фичи собираются в манифесте приложения, который хост может загрузить за dynamic boundary. Хост передаёт
+platform-адаптеры через `bind` и монтирует consumer-owned targets:
+
+```ts
+const sampleAppApplication = defineApplication({
+  id: 'sampleApp',
+  features: [catalogCatalogFeature, createFormFeature],
+  reporter: error => sentry.capture(error),
+});
+
+const execution = openApplication(sampleAppApplication, {
+  conditions,
+  imports: [bind(catalogHost, catalogSource), bind(createFormHost, createFormSource)],
+});
+```
+
+```tsx
+<Slot props={{ itemId }} target={orderFormContentSlot} />
+```
+
+Что здесь не видно и не должно быть видно автору: module, fence, retire, drain, quarantine, lane-lease,
+publication barrier. Всё это принадлежит runtime и его integration-слою.
+
+### 2.1 Секции `defineFeature`
+
+| Секция      | Отвечает на вопрос                          | Форма                                                                                                                                                                  |
+| ----------- | ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `id`        | Как фича называется                         | `'feature.entity'`, только точки, без суффиксов                                                                                                                        |
+| `imports`   | Что мне дадут снаружи                       | запись из `defineHostContract` контрактов и определений других фич; `optional(x)` это слабое ребро, `onDemand(hostContract)` откладывает подключение до первого вызова |
+| `requires`  | Какой порт мне нужен                        | запись `port` или `optional(port)`; каждое `requires.x` это ref, а `Call` появляется у экземпляра                                                                      |
+| ref vs Call | Что видно в какой стадии                    | `own` и внешняя фабрика `provides` видят refs; `exports` и вложенные фабрики вкладов видят материализованные значения экземпляра                                       |
+| `own`       | Чем я владею                                | builder: `model`, `call`, `calls`, `lane`, `effect`, `event`, `resource`, `stream`, `scope`, `attach`                                                                  |
+| `exports`   | Что я отдаю фичам, которые меня импортируют | `({ own }) => запись Call, Readable и Resource` на открытии экземпляра                                                                                                 |
+| `provides`  | Что я предлагаю точкам расширения           | `({ port, slot, pipe, register, own }) => ...`                                                                                                                         |
+| `when`      | Сколько фича живёт                          | список `Condition`; пустой или отсутствующий это постоянная фича                                                                                                       |
+
+Обязателен только `id`. Стадии видят только предыдущие: `imports`, `requires` → `own` → `exports`, `provides`.
+Секции `ui` нет: UI входит в приложение вкладами.
+
+Фичу можно написать и двумя файлами (D186, D207). Заголовок держит `id`, `imports`, `requires`, `provides`
+как метаданные — цель каждого вклада с его приоритетом, порт каждого провайдера — а также `when` и `body: () => import('./feature.body')`;
+файл тела пишет `defineFeature.body(header, { own, exports, provides })`, а loader заголовка называет границу
+экспортов как `FeatureBody<Exports>`, поэтому заголовок не зависит от типа собственного тела. Consumers и приложение
+импортируют только заголовок: вся топология, её циклы и вложенность времён жизни компилируются до того, как загружен
+хоть байт тела. Тело загружается при открытии экземпляра, один раз на фичу и совместно для одновременных
+потребителей; загруженное тело переиспользуется следующими экземплярами, неудачная загрузка не кэшируется, а
+закрытие или фенс до прихода кода означают, что экземпляр не откроется вовсе. `defineFeature.preload(feature)`
+подтягивает код, ничего не открывая, — для хоста, который уже знает, что фича вот-вот понадобится.
+
+### 2.2 Слой моделей
+
+Модель это единица владеемого состояния и поведения фичи. Объявление `defineModel<Shape>(id)` живёт в
+`features/x/models/` или в контрактах UI и задаёт запись из `Readable` и `Call`; класс в качестве `Shape` не
+проходит типом. Реализация это фабрика `(ctx: ModelContext, deps) => Shape` или класс `implements ModelOf<typeof X>`,
+получающий `ctx` и `deps` в конструктор. `ModelContext` без generic: `state`, `update`, `call`, `calls`, `lane`,
+`effect`, `event`, `resource`, `stream`, `scope`, `timers`, `cleanup`, `signal`. `ctx.calls(deps, [...], { lane, policy })`
+выбирает из зависимостей методы форм `() => Output`, `(input) => Output` и `(input, signal: AbortSignal) => Output`
+и отдаёт по одному `Call` на ключ — тот же выбор и
+тот же вывод типов, что у `own.calls`, плюс необязательная lane модели и политика, с которой создаётся каждый
+выбранный вызов. Метод без параметров получает input `void`; необязательный input сохраняет `undefined`. Второй
+параметр должен быть точно `AbortSignal` или `AbortSignal | undefined`, в том числе необязательный signal.
+Поля данных, сигнатуры с `any`, неограниченный rest и сигнатуры с возможным третьим аргументом не выбираются.
+Ограниченный tuple rest длиной до двух параметров подчиняется тому же правилу. Для overload действует вывод
+TypeScript по последней сигнатуре; для другой перегрузки нужен явный адаптер (D244). Политика вызова пишется там, где он создаётся —
+`ctx.call`, `ctx.calls`, `own.call`, — и действует для всех вызывающих, которых вызов допускает, включая
+`context.invoke(target, input)` (D185). `ctx.cleanup(disposer)` регистрирует владеемую уборку: диспозер выполняется в том же drain, что и
+диспозеры `effect`, `event`, `resource`, `stream` и `scope`, в обратном порядке регистрации, его отказ уходит в
+`reporter`, а вызов после фенса это `TypeError`, как у `timers` после закрытия. `ctx.state` возвращает
+`OwnedState<Value>`, и только его принимает `ctx.update`: производный `Readable` не проходит типом. Зависимости
+модель объявляет своим интерфейсом, фича подставляет их в `own`. UI получает модель через `useModel(Decl)` только
+внутри монтирования вклада, который её выдал.
+
+**Объявление и исполнение (D243).** `ctx.call(options)` в контексте фабрики модели и `own.call(options)` объявляют
+команду; `ctx.calls(source, keys, options?)` или `own.calls(source, keys)` объявляет несколько. Обработчик `run` получает другой контекст:
+`context.invoke(target, input)` исполняет существующую команду с текущим авторитетом, отменой и стеком lane.
+Деструктуризация поддерживается: `run: (input, { invoke }) => invoke(deps.submit, input)`. Политика остаётся в
+объявлении; `invoke` не добавляет планировщик или переопределение политики.
+
+Это breaking-переименование без алиаса `call` в контексте исполнения. Одновременно перенесите обращения к полю,
+деструктуризацию и собственные аннотации типов контекста. Методы фабрики и типы `Call` и `CallInvocation` сохраняют имена:
+
+```diff
+ const submit = ctx.call({
+-  run: (input: Input, { call }) => call(deps.submit, input),
++  run: (input: Input, { invoke }) => invoke(deps.submit, input),
+ });
+-await context.call(submit, input);
++await context.invoke(submit, input);
+```
+
+То же переименование действует для существующего права вызова в `ModelCallContext`, `FeatureCallContext` и
+доверенных контекстах исполнения attachment, включая `ModuleAttachmentExecutionContext`, передаваемый в `context`
+шага `step`. Контексты без права вызова его не получают; callbacks сохраняют свои документированные возможности.
+
+**Время жизни сигналов (D244).** Используйте сигнал callback, который выполняет работу:
+
+| Сигнал                                          | Время жизни                                                                                                                                                         |
+| ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `ModelContext.signal`                           | Вся владеемая модель. Он не подходит для отмены одного запроса.                                                                                                     |
+| `signal` контекста `run` команды                | Одно физическое исполнение команды. Вложенный `invoke` наследует отмену, авторитет и стек lane; у ожидающих `singleFlight` сохраняются отдельные логические исходы. |
+| `signal` контекста `Resource.load`              | Активная загрузка текущего поколения target; замена, refresh, retirement или закрытие владельца могут отменить её, пока модель жива.                                |
+| `signal` контекста `Stream.connect` / `consume` | Текущее исполнение соединения; замена, retry или retirement отзывают его право работать и дожидаются допущенной работы перед открытием преемника.                   |
+
+`calls` всегда вызывает выбранный метод с `(input, signal)` и сохраняет его receiver. Обычный метод может
+игнорировать лишние аргументы; фиктивный `_signal` не требуется. Единственный параметр с именем `signal` остаётся
+input, а не автоматически переданным токеном отмены. Options клиента и дополнительные аргументы преобразуйте
+небольшим обычным адаптером, например `load: (input: Input, signal: AbortSignal) => client.load(input, { signal })`.
+Нет проверки `Function.length`, угадывания аргументов или дополнительного primitive адаптера. Метод, игнорирующий
+отмену, может продолжить работу после логической отмены вызывающего. Runtime отвергает поздний результат Call и
+управляет публикацией завершённых Resource/Stream executions; он не может остановить произвольные записи состояния
+и внешние побочные эффекты внутри метода. Для них сам метод должен проверять signal. Физический drain продолжает
+ждать уже запущенную работу.
+
+Фича собирает зависимости через `model(Decl, { platform: imports.platform, lookup: requires.lookup }, create)`;
+второй аргумент фабрики — readonly-запись разрешённых значений с выведенными типами. Для одного источника
+используется та же запись, без зависимостей — `model(Decl, create)`. Принимаются только подлинные импорты и call
+refs текущей фичи; optional-импорты сохраняют `Readable<Lookup<…>>`. Сырые объекты хоста, декларации портов,
+чужие refs и refs моделей не являются элементами зависимостей. Именованная фабрика может объявить свой интерфейс
+зависимостей, не видя контекста фичи. `provides.port(SubmitPort, { from: own.order, select: order => order.submit })`
+один раз выбирает подлинный вызов из готовой модели до публикации и добавляет фенс провайдера, включая
+переданные напрямую вызовы. Локальный call ref по-прежнему использует `port(SubmitPort, own.submit)` (D169).
+
+Моделей у вклада два вида, и обе объявлены одним `defineModel`. Модели `own` живут с экземпляром фичи и служатся
+монтированию автоматически. UI-модель вклада живёт с монтированием: она перечислена в `models` вклада, её фабрика
+получает вторым аргументом `Readable` пропсов этого монтирования и берёт поля как есть (`submit: exports.submit`)
+или оборачивает их в `ctx.call`, когда контракт UI отличается входом, формой результата или числом фичевых вызовов.
+Отдельного понятия View нет.
+
+### 2.3 UI
+
+UI входит в приложение одним путём: `provides.slot(target, { Component, props?, models? })` публикует компонент, а
+`Slot` рендерит его внутри авторитета фичи-контрибьютора. Внутри вклада работают `useModel` на модели его экземпляра и
+на UI-модели, объявленные вкладом, а поверх их полей — `useCommand`, `useReadable`, `useSelector`, `useResource`.
+Пропсы слота типизированы целью: без адаптера компонент принимает их как есть, с адаптером `props` — ровно результат
+адаптера. `requiresModels([...])(Component)` перечисляет UI-модели, которые компонент читает: тип проверяет, что вклад
+выдал каждую из них. Выдача гибридная: модели `own` фичи служатся неявно любому компоненту поддерева монтирования, а
+per-mount UI-модель обязан объявить тот компонент или хук того же модуля, который читает её через `useModel`.
+Объявление принадлежит каждому читателю, а не только месту вклада (см. decisions.md, D158).
+
+`opetope/require-declared-models` из recommended `@opetope/lint` проверяет видимые `slot`-вклады и readers моделей в пределах одного модуля. Он учитывает aliases импортов и локальные bindings, включая именованные компоненты. Импортированные реализации и динамические объявления остаются непроверенными; отсутствие диагностики не доказывает полноту их требований (D250).
+
+Хуки: `useModel`, `useReadable`, `useSelector`, `useCommand`, `useCommands`, `useResource`. Компоненты: `Slot` и `FeatureBoundary`
+из `@opetope/react/integration`, который держит фичу открытой и показывает `fallback` или `error`. Обе ветви
+принимают либо узел, либо render-колбэк: `children` получает готовый экземпляр, типизированный по `demand`, `error`
+получает `{ error, retry }`, выполняется только показанная ветвь, и готовому потребителю не нужны второй
+`useFeature` и второе удержание (D177). Команда через
+`useCommand` следует объявленной политике Call, не превращает отмену экземпляра в ошибку пользователя и держит последний
+исход в `result` и `lastError`; режима наблюдения у команды нет, состояние чужой инвокации модель отдаёт полем
+`Readable`. Тесты компонента используют `renderSlot(target, { props, models, contribution })` и `command(run)` из
+`@opetope/react/testing`.
+
+`run` сохраняет ссылку, пока invoker тот же; объект результата хука меняется со статусом.
+Эффект, вызывающий команду, зависит от `run`; `run` сохраняет идентичность, пока не меняется invoker. Своей политики
+у потребителя нет: каждый `run` доходит до вызова, и решает политика, с которой вызов создан (D203). За потребителем
+остаётся только то, что знает он один: уже отменённый входной signal отвергается как `cancelled`, не доходя до
+вызова, `run` размонтированного потребителя отвергается так же, `inFlight` истинен, пока не завершился хоть один
+начатый им прогон, и у каждого прогона свои исход, callbacks и signal. Два потребителя одного вызова держат
+раздельные статусы.
+
+`useModel(Declaration, (model, { read }) => ({ ... }))` выбирает данные и command consumers одним hook (D205, D214).
+
+Результат выбора модели может быть именованным interface без index signature (D217). Результат — плоская запись данных;
+arrays, functions, constructors и встроенные объекты коллекций, дат и promises не являются selection records.
+Readonly record с выведенными типами преобразует authentic Call в `CommandHook`; остальные поля сохраняют свои типы.
+`read(readable, project?)` читает явно, объединяет подписки на один источник и не делает автоматический Resource retain.
+Поля сравниваются через `Object.is`; новый вложенный объект считается изменением. Чистый callback не вызывает hooks,
+команды или side effects. Замена подписок и допуск команд происходят в commit, не в abandoned render. Ключи, aliases,
+локальные статусы и `.run` следуют `useCommands`. Создание модели, feature acquire и новый scheduler не подразумеваются.
+`useModel(Declaration)` по-прежнему возвращает выданную модель; структура React hooks постоянна при смене selection.
+Общий hook улучшает DX, но сам по себе не гарантирует ускорение.
+
+`useCommands({ save: model.save, remove: other.remove })` возвращает `CommandHook` на каждом ключе, с точными
+разнородными типами (D174). Ключи — локальные имена; команды берутся из разрешённого авторитета моделей. Общей
+очереди, транзакции или busy нет, и опции нет: политика принадлежит каждому вызову. Пока ключ и invoker те же,
+`.run` стабилен, а объект поля меняется только с его статусом. Новый объект выбора и перестановка ключей не меняют
+ничего. Удаление ключа отбрасывает его потребителя и статус; повторное добавление создаёт нового. Два псевдонима
+одного Call — независимые потребители. Выбираются собственные enumerable-поля (включая symbols); число React hooks
+постоянно при изменении набора ключей. Только commit активирует новый выбор: отброшенный рендер не трогает
+закоммиченных потребителей. Одиночный `useCommand` остаётся.
+
+Прямые пропсы компонента и props-адаптер читают тот же снимок монтирования, что читатели модели; входящие пропсы
+слота публикуются в layout до paint, без обновления состояния в insertion effects. Retry спроса `FeatureBoundary`
+принадлежит своему источнику: замена A на B не заставляет B ждать незавершённого retry A (D170). `useFeature(...).retry`
+возвращает промис, который разрешается по завершении начатой им попытки, а второй вызов во время работы присоединяется
+к той же попытке, а не начинает новую. Он отвечает этим промисом и тогда, когда источник отказал в acquisition
+синхронно: отказавшая acquisition это завершившаяся попытка, а сам отказ принадлежит состоянию, которое публикует
+источник, а не вызывающему `retry` (D226). Граница показывает `fallback` всю жизнь попытки и перечитывает состояние по её
+завершении, поэтому попытка, упавшая с тем же объектом ошибки, который хост уже держит, возвращает поддерево `error`
+(D198). `retry` поддерева ошибки остаётся `() => void`: хост вправе отдать его прямо в `onClick`.
+
+`resource(from, target, options)` и `stream(from, target, options)` принимают селектор, возвращающий
+`Readable<T | null | undefined>`, и в контексте фичи, и у модели. Скалярный snapshot недопустим; nullish target
+закрывает материализацию. Retention необязателен; `scoped({ capacity })` выбирает ограниченное LRU-удержание.
+`effect({ from, when, run })` проверяет `when(current, previous)` для каждого выбранного запуска.
+`calls(imports.x, keys)` выбирает методы хоста, экспортированные вызовы жёсткого импорта фичи или — поверх
+`optional(feature)` — экспортированные вызовы того провайдера, который есть сейчас: выбранный вызов доходит до живого
+экземпляра, а пока провайдера нет, отвечает `CallError` с кодом `unavailable` (D187). Данные слабого ребра читаются
+через `fromOptional(source, select, { missing })`: `select` выполняется только на `found` и вправе вернуть значение
+или собственный `Readable` провайдера, вложенный readable отслеживается только пока провайдер есть, а всё остальное
+время ответ это `missing`.
+
+### 2.4 Приложение и хост
+
+```ts
+const authorized = defineCondition({ id: 'workspace.authorized' }); // факт, который привязывает хост
+const premium = defineCondition({ from: authFeature, id: 'workspace.premium', select: e => e.premium });
+
+const sessionsFeature = defineFeature({ id: 'workspace.sessions', when: [authorized] /* … */ });
+
+const workspaceApp = defineApplication({
+  id: 'workspace', // runtime-идентичность приложения
+  features: [authFeature, sessionsFeature, catalogFeature], // включённые фичи; мир замыкается по импортам
+  reporter: error => sentry.capture(error),
+});
+
+openApplication(workspaceApp, {
+  conditions: {
+    'workspace.authorized': derive({ from: example.session, select: session => session.status === 'authorized' }),
+  },
+  imports: [bind(authHost, example), bind(sessionsHost, agents)],
+});
+```
+
+Время жизни объявляет сама фича. `defineCondition({ id })` это факт, который привязывает хост;
+`defineCondition({ from, id, select })` вычисляет факт из экспортов одной фичи, и такой id хост привязывать не
+имеет права. `defineFeature({ when: [условия] })` говорит, что фича живёт, пока все её условия истинны; пустой или
+отсутствующий `when` это постоянная фича. `defineApplication({ id, features, reporter })` компилирует статическую
+топологию до старта: `requires ↔ provides`, `imports`, вклады. `features` это список включённых фич, а мир это они
+плюс транзитивное замыкание их жёстких импортов, поэтому провайдер порта должен быть включён, иначе порт остаётся
+без провайдера. Фичи с одинаковым набором условий образуют группу условий: она даёт порядок активации и узел в
+devtools-плане, отдельного объявления группы нет. `openApplication` поднимает приложение: `conditions` это запись
+`Readable<boolean>` по id, типизированная из `Application<Features>` как объединение id условий без `from`,
+`imports` это массив `bind(contract, value)`, проверяющий значение в месте вызова. Необязательный `cleanupFailure`
+несёт те же два слова, что у `openFeature`, и по умолчанию равен `report`: хост, выбравший `quarantine`, оставляет
+провалившуюся уборку точным фронтиром на `FeatureError.retryCleanup` вместо отчёта, и порт управления devtools может
+её повторить (D182).
+
+---
+
+## 3. Публичный словарь
+
+Правила имён: `define*` объявляет контракт без поведения; `use*` читает в React; `open*` поднимает lifetime; методы
+builder-а без префикса; ошибки `<Subject>Error` с полем `code`. Kernel-слово это имя механики, которой автор фичи не
+управляет: `Module`, `Attachment`, `Executor`, `Authority`, `Owner`, `Blueprint`, `IR`. Такое слово живёт только в
+`internal`, не появляется ни в одном имени на безопасном входе и не появляется в тексте авторской ошибки — там
+говорят «feature» и «instance». `module` это единица lowering, из которой kernel собирает фичи и детей динамического
+scope: отдельный концепт, а не второе имя фичи. Оба запрета держит гейт `ci:public-surface`.
+
+**`@opetope/core`.** Значения `computed`, `derive`, `fromOptional`, `externalReadable`, `collection`, `selectByKey`,
+`declarationId`, `defineModel`, `definePort`, `definePipe`, `defineRegistry`. Типы `Readable`, `State`, `OwnedState`, `Collection`,
+`Lookup`, `Equality`, `Model`, `ModelOf`, `ModelContext`, `Call`, `Port`, `PortRef`, `Pipe`, `Registry`,
+`DeclarationId`, `Resource`, `ResourceSnapshot`, `ScopedRetention`, `LatestBackpressure`. Ошибки
+`CancellationError`, `FeatureError`, `ReadableError`, `DeclarationError`, `CallError`; коды `CallError` это
+`cancelled`, `closed`, `publication-rejected`, `unavailable`. `createState` и `isCancellation` живут на
+`@opetope/core/internal`: у автора нет пилота ни на своё состояние вне модели, ни на распознавание отмены руками —
+состояние приходит из `ctx.state`, а отмену читает `useCommand`.
+
+**`@opetope/runtime`.** Значения `defineFeature`, `defineHostContract`, `onDemand`, `optional`,
+`openFeature`, `defineCondition`, `defineApplication`, `bind`, `openApplication` и политики `scoped`, `latest`.
+Типы `Feature`, `FeatureInstance`, `HostContract`, `Condition`, `Application`, `ApplicationExecution`,
+`ApplicationImportBinding`, `FeatureBody`, `FeatureBodyOf`, `Resource`, `ResourceSnapshot`, `ScopedRetention`, `LatestBackpressure`, `ErrorReporter`,
+`CleanupFailurePolicy`, а также re-export `Call` и `Readable`. Ошибки `FeatureError` (re-export) и
+`ApplicationError`.
+
+**`@opetope/react`.** Значения `useModel`, `useReadable`, `useSelector`, `useCommand`, `useCommands`, `useResource`,
+`requiresModels`, `Slot`, `defineSlot`, `defineSwitchSlot`. Типы `SlotTarget`, `SwitchSlotTarget`,
+`SlotContribution`, `CommandHook`, `CommandOutcome`. Ошибка `ContributionError` несёт коды `binding-invalid`,
+`duplicate`, `inactive`, `missing`: её субъект это монтирование вклада, которое и выдаёт модели, и фенсит команды,
+поэтому отдельных `ModelError`, `RootError` и `ActionError` нет.
+
+**`@opetope/react/integration`.** `FeatureBoundary`, `useFeature`, `useFeatureRetry`,
+`FeatureBoundaryError`. **`@opetope/react/testing`.** `renderSlot`, `command`, `createScenario`, `ScenarioTimeoutError` и типы fixtures/scenarios. `useFeatureError`-а нет: ошибку,
+которую хост сам передал в `error`, он уже знает, а контекст boundary остаётся внутренним для `useFeatureRetry`.
+
+**Возможности lifecycle.** `FeatureInstance` предоставляет `ready` и `close()`. Закрытие фенсит немедленно и
+присоединяется к одному promise завершения. `FeatureError.retryCleanup?: () => Promise<void>` существует только
+у карантинной ошибки с повторяемой уборкой; перед вызовом проверяется наличие capability. Внутренний термин
+и код отмены `retired` сохраняются. Retry ресурса и retry спроса фичи сохраняют свой смысл. Прежние авторские
+имена `retire`, `FeatureError.retry`, `effect.condition`, `required(port)` и опция `scoped` `evict` не имеют
+алиасов (D168).
+
+**Внутри `defineModel`.** `ModelContext` по §2.2, где `scope` читается как `scope.while`, `scope.switch`,
+`scope.keyed`.
+
+**Внутри `defineFeature`.** Секции §2.1; методы `own`: `model`, `call`, `calls`, `lane`, `effect`,
+`event`, `resource`, `stream`, `scope.while`, `scope.switch`, `scope.keyed`, `attach`. У `resource`,
+`stream` и `event` источник и носитель вывода типа позиционные: `resource(from, target, {…})`,
+`stream(from, target, {…})`, `event(from, subscribe, {…})`; порядок ключей в объекте опций свободен. Одна опция
+несёт для обоих одно слово: `stream` требует `backpressure: latest()`, а `event` его допускает. Методы `provides`:
+`port`, `slot`, `pipe`, `register`; у вкладов цель первым аргументом, значение или фабрика экземпляра вторым, опции
+третьим: `slot(target, contribution, { priority, when })`, `pipe(target, { fold }, { priority, when })`,
+`register(target, entry, { priority, when })`, причём у `pipe` второй аргумент это дескриптор, потому что голую
+функцию было бы не отличить от фабрики экземпляра. Контекст фабрики вклада это `{ exports, imports, instance, model, own }`, и его
+`model(Decl, create)` строит UI-модель монтирования, где `create` получает `(ctx, props)`. `when` это
+`Readable<boolean>` или предикат экземпляра — `({ exports, imports, own, read }) => boolean`, — чей `read`
+записывает, от чего зависит ответ: пока ответ `false`, вклад не входит в `entries` цели. В этом контексте
+вычисления `own` дан в материализованной форме, которую видит `exports`: поле модели это `Readable`, а не ref из
+контекста фабрики. `fold` дескриптора `pipe` получает третьим аргументом тот же контекст вычисления —
+`(value, meta, { exports, imports, own, read }) => …`, — связанный с экземпляром один раз при публикации вклада и
+вызываемый только сверткой, а не при объявлении или предзагрузке; а `target.fold(value, meta, read?)` принимает
+читателя третьим параметром, поэтому `computed({ read: read => target.fold(0, undefined, read) })` подписывается и
+на `entries`, и на всё, что прочитали обработчики; без читателя обработчики читают текущий snapshot. Контексты:
+`source`, `signal`, `invoke`, `update`, `timers.delay`, `timers.interval`, `cleanup`, `current`, `previous`, `emit`,
+`payload`.
+
+Итого: 39 value-экспортов и 35 типов на трёх безопасных входах по гейту `ci:public-surface` при цели 40 и 60.
+Ежедневный словарь автора фичи около 20 слов.
+
+**`@opetope/core/internal` и `@opetope/runtime/internal`**, для реализации фреймворка и интеграции хоста: `defineModule`,
+`instantiateModule`, все `Module*` и `Attachment*`, call-kernel `defineCallTarget`, `createCallExecutor`,
+`defineCallLane`, публикация вкладов `publishContributions`, `bindFeatureResource`, `getApplicationPlan`,
+`createState` и `isCancellation`. Состав входов ограничен фактом потребления: value-экспортов 43 в ядре и 20 в
+рантайме, и всё, что не импортируют вне пакета, осталось модульным (см. decisions.md, D159). У `@opetope/react`
+внутреннего входа нет.
+
+---
+
+`@opetope/devtools/react` экспортирует `defaultTheme` — нейтральную самостоятельную палитру. Приложение настраивает панель через `DevtoolsTheme`; переопределения ограничены корнем панели (D249).
+
+## 4. Законы ядра
+
+Каждый закон доказан тестами пакетов и не меняется переименованиями.
+
+- **Ownership и экземпляр фичи.** Всё созданное в `own` живёт и умирает с экземпляром фичи. Каждое вложение
+  подключает импорт или host-контракт: владеемых scope-ов у фичи нет, поэтому «на экземпляр» значение приходит
+  ровно одним путём — через `imports` (см. decisions.md, D141). Retire сначала делает экземпляр stale и fence-ит
+  команды, затем уведомляет, затем закрывает своих детей. Порядка между вложениями одного scope-а нет: они
+  открываются и закрываются одной волной, а карантинный фронтир докладывается в каноническом порядке слотов
+  (см. decisions.md, D163). Порядок между фичами разных групп условий держит порядок групп, а не этот закон. Поздний результат старого экземпляра не публикуется.
+- **Физический дренаж и откат.** Логическая отмена быстро завершает ожидание вызывающего, но не означает, что
+  пользовательская работа остановилась. Дренаж ждёт допущенную работу, включая незавершённое открытие и consume
+  стрима, до освобождения источника. Модели регистрируют владельца отката до вызова фабрики, включая per-mount
+  модели вкладов. Отказ фабрики убирает частично созданные узлы. Фенс закрывает всё владеемое состояние и
+  отвергает новые узлы того же контекста; `OwnedState` соседней модели недоступен ему для записи (D170).
+
+- **Координированное закрытие.** Закрытие, уже идущее у одного вложения, не отменяет закрытия остальных:
+  координированный fence присоединяется к этому drain-у и докладывает его исход, поэтому один член в откате не стоит
+  соседям их закрытия.
+- **Cleanup.** По умолчанию `report`: ошибка cleanup уходит в reporter приложения, экземпляр считается закрытым.
+  `quarantine` это явный opt-in для ресурсов с обязательным физическим release.
+- **Данные.** Один scheduler стабилизирует `derive` и `computed`, уведомление один раз на транзакцию, `selectByKey`
+  не создаёт cross-key уведомлений.
+- **Осевшее чтение.** Чтение активного чистого узла не обходит граф: оно отдаёт осевшее значение, потому что вверх
+  по графу всё уже опубликовалось (см. decisions.md, D130).
+- **Транзакционная активация.** Отказ на середине откатывает узлы, которые активация успела пройти, в обратном
+  порядке, и отказы диспозеров при откате приезжают вместе с исходной причиной.
+- **Распространение закрытия.** `close()` у `State` это одно уведомление зависимым узлам, после которого `derive`,
+  `computed`, `collection` и `selectByKey` отвечают `ReadableError` с кодом `closed` вместо последнего значения, и
+  дальше молчат; неподписанный производный узел получает тот же отказ на следующем чтении закрытого источника.
+  Закрытие терминально и для того кода, который его вызвал: апдейтер, закрывший состояние по ходу вычисления,
+  получает отказ на свой результат, а состояние остаётся закрытым (D201).
+- **Lookup.** `Lookup` литерален: `{ kind: 'found', value } | { kind: 'missing' }`, и та же форма проецирует слабое
+  ребро.
+- **Вызовы.** `call` по умолчанию `queue`, `parallel` явно, `latest` держит одно ожидающее место, `once` кэширует,
+  `singleFlight` дедуплицирует по ключу; вложенный вызов только через `context.invoke`, отмена и lane наследуются.
+- **Latest.** Вызов, объявленный `latest`, идёт по lane как `queue`, и пока его тело исполняется, новый вход
+  заменяет ожидающий: вытесненный invocation завершается отменой со своими колбэками и сигналом, а тело в полёте не
+  прерывается. Замена останавливается на границе lane: если за ожидающим уже встал другой вызов, ожидающий остаётся
+  на своём месте, а новый вход ждёт после него. Цена 100, отправка и цена 200 на одной lane поэтому отправляют 100
+  и затем применяют 200 (D185).
+- **Доставка событий.** `event` исполняет один payload за раз, а за ним слот ещё на один. `backpressure: latest()`
+  отдаёт этот слот новому payload и ничего не репортит; `event`, написанный без опции, оставляет слот тому payload,
+  который занял его первым, и отбрасывает новый `emit` записью отказа `queue-capacity`. Ни одна политика не
+  прерывает идущий `run`, ни одна не держит больше одного ожидающего payload, а закрытие владельца отбрасывает то,
+  что ждёт. Очередь без потерь это отдельный вопрос (D183, D247).
+- **Исходы команды.** `useCommand` не превращает отмену в ошибку и держит последний исход: `result` от последнего
+  `ok`, `lastError` от последнего `failed`, `cancelled` не двигает ни то, ни другое, и старт прогона не чистит ни
+  то, ни другое, поэтому прежний отказ читается, пока повтор в полёте. Отсутствие провайдера и отклонённая
+  публикация приходят исходом `failed` и оседают в `lastError`.
+- **Публикация.** Вклады публикуются атомарно после critical-барьера открытия владельца и до разрешения публичного
+  `instance.ready`, затем снимаются при retire; цели вкладов статичны,
+  поэтому топология компилируется до старта. Цель держит один вклад на ключ фичи, поэтому два живых экземпляра одной
+  фичи не могут одновременно вкладываться в одну цель.
+- **Удержанный вклад.** Вклад с `when` в `false` опубликован, но не входит в `entries` цели, поэтому `Slot`, `fold`,
+  `select` и проверки пустоты его не видят; смена значения пересчитывает `entries` одной транзакцией. Предикат
+  понижается в один computed-readable своего экземпляра до начала публикации, поэтому дальнейшие пути одинаковы для
+  обеих форм, а ответ не-boolean роняет это чтение, а не публикует truthy-объект как видимость (D220). Уникальность
+  id и ключей проверяется по всем опубликованным вкладам, поэтому смена `when` не может провалить валидацию.
+- **Атомарность публикации.** Публикация держит чужой код вне своих записей. Подписка на `when` и его чтение идут до
+  того, как хоть одна цель тронула свои `entries`, — чтение после подписки, поэтому источник, перевернувший своё
+  значение изнутри `subscribe`, публикуется в том состоянии, в котором остался, — а освобождение наблюдателя,
+  оставшегося от ушедшей записи, идёт после того, как зафиксированы все цели этой публикации: снятие, сделанное из
+  такого disposer, удаляет из уже зафиксированного состояния, а не отменяется им. Публикация читает `when` только
+  своих записей; каждый другой владелец сохраняет видимость, с которой был опубликован в последний раз, поэтому
+  обязательное снятие не читает `when` вообще, а нечитаемый предикат не может удержать в цели записи другого
+  владельца (D225). `when`, подавший сигнал во время проекции публикации, делает эту проекцию недействительной, и
+  затронутые цели проецируются заново; источник, подающий сигнал на каждое чтение, роняет публикацию громко, а не
+  коммитит то, что он ответил до сигнала. Цель, отказавшая в публикации, откатывает подписки, сделанные предыдущими
+  целями, поэтому несостоявшаяся публикация не оставляет ни одного слушателя, а отказ снятия убирает и то, что успело
+  лечь. Смена `when`, сделанная изнутри слушателя `entries`, не теряется: охранник от реентрантности её запоминает, и
+  цикл её публикует.
+  Последующий пересчёт видимости также сверяет точный состав entries и ревизию видимости после каждого getter.
+  Устаревшая проекция отбрасывается до чтения снятого соседа и публикации старых entries; после 100 повторов
+  пересчёт завершается с `TypeError` и освобождает guard, чтобы следующее стабильное уведомление могло восстановить
+  снимок (D242).
+- **Открытие и закрытие фичи.** Eager-определение и lazy-заголовок проверяют и копируют запись options, imports и
+  requirements в `openFeature`, до вызова loader; последующая замена этих полей не меняет экземпляр. `close()`
+  фенсит синхронно, а параллельные и реентерабельные вызовы получают один Promise завершения. Ошибка loader,
+  включая синхронный throw, отклоняет `ready` или `preload`. Закрытие до прихода кода отклоняет `ready` этого
+  экземпляра как `retired` и завершается, не ожидая общей загрузки. Загрузка остаётся доступна другим экземплярам
+  и preload; поздний успех не открывает закрытый экземпляр, а отказ допускает повтор. Если материализация уже
+  началась, close дожидается владеемой работы и сохраняет восстановление из quarantine (D211).
+- **Запуск приложения.** Закрытие из подписки условия или её disposer получает тот же Promise, что и остальные
+  вызовы close. Оно фенсит уже созданные группы, снимает подписку, вернувшуюся после закрытия, не создаёт следующих
+  групп и отклоняет готовность приложения; `close()` дожидается всей начатой уборки (D210).
+- **Порты.** У порта ровно один провайдер, выбор на уровне приложения, два провайдера это ошибка компиляции
+  топологии.
+- **Время жизни как условия.** Время жизни объявляет фича: она живёт, пока истинны все условия её `when`, и пустой
+  `when` значит «пока живёт приложение». Фичи с одинаковым набором условий образуют одну группу, поэтому набор, а не
+  порядок, определяет владельца. Условие это желаемое состояние, а не событие: рантайм следует последнему снапшоту,
+  поэтому значение, успевшее стать `false` и снова `true` в одном turn, сохраняет живое поколение, а конец сессии
+  выражается фактом в самом условии — например её id, — а не кратким `false` (D190).
+- **Закон включения.** Жёсткое ребро законно только когда набор условий провайдера это подмножество набора
+  потребителя: провайдер обязан жить не меньше, иначе компилятор отказывает и указывает на `optional`. Тот же закон
+  держит условие с `from`: фича-источник обязана жить не меньше того, что условие гейтит. Группа открывается в
+  каноническом порядке своих фич и закрывается в обратном, а условие, вычисленное из закрытой фичи, читается как
+  `false`.
+- **Слабое ребро.** `optional(x)` в `imports` и `optional(port)` в `requires` это одно слово и одно значение: ребро,
+  на котором потребитель может жить дольше провайдера. Экспорты приходят проекцией `Readable<Lookup<Exports>>`,
+  ресурсы за ней недостижимы, пока проекция говорит `missing`, а вызов слабого порта оседает исходом `CallError` с
+  кодом `unavailable`, пока живого провайдера нет, — это ошибка, а не отмена. Причина отсутствия не различается:
+  провайдера нет в приложении или его группа условий закрыта — выглядит одинаково.
+- **Сахар слабого ребра.** У двух половин слабого ребра по одному слову: `calls(imports.x, keys)` для
+  экспортированных вызовов провайдера и `fromOptional(source, select, { missing })` для его данных. Обе читают
+  провайдера в момент использования, поэтому новый экземпляр подхватывается без пересборки, вызов в полёте
+  завершается фенсом самого провайдера, а от отсутствующего провайдера не удерживается ничего (D187).
+- **Инертность слабого ребра.** Слабое ребро не втягивает провайдера в мир приложения и никогда не влияет на порядок
+  активации: провайдер открывается со своей группой условий, кто бы его ни импортировал. Закон включения держится
+  только для жёстких рёбер, а сообщение компилятора при его нарушении указывает на `optional`
+  (см. decisions.md, D105).
+- **Экспорт.** `exports` вычисляется на открытии экземпляра из уже материализованного `own`, поэтому запись несёт
+  живые значения: `Call`, `Readable` и `Resource` того самого экземпляра, а не снимок и не ref. Модель целиком не
+  экспортируется — только её поля, потому что модель это запись значений, а не значение. Владеемое состояние выходит
+  наружу суженным до `Readable`: писатель остаётся у владельца, и это проверяет тип.
+- **Видимость на жёстком ребре.** На жёстком ребре провайдер открывается раньше потребителя, а потребитель
+  закрывается раньше провайдера, поэтому потребитель никогда не видит закрытых значений. После retire провайдера
+  экспортированный `Readable` закрыт на фенсе, поэтому подписчик слышит это один раз, а чтение даёт `ReadableError`
+  с кодом `closed`.
+- **UI authority.** `useModel` разрешает только модели, выданные монтированием вклада: модели его собственного
+  экземпляра плюс UI-модели, объявленные вкладом. Выдача гибридная: модели `own` доходят до любого компонента
+  поддерева неявно, per-mount модель объявляет тот компонент или хук, который её читает, и эту границу держит
+  lint-правило, потому что кадр монтирования один и вложенных читателей сам по себе не различает. Обхода дерева и
+  доступа к чужим фичам нет, frame стабилен, update модели не меняет Context.
+- **Совместимость React.** `@opetope/react` поддерживает React `>=19.0.0 <20`; UI и браузерная интеграция Devtools поддерживают согласованные версии React/React DOM в этом диапазоне. Приёмка релиза устанавливает отдельные наборы React/React DOM и их типов версии `19.0.0` и версий contributor toolchain, затем проверяет типы NodeNext/Bundler, рендеринг с моделями, команды, demand и монтирование/размонтирование Devtools на Node 20.19+ (D251).
+- **Время жизни монтирования.** Экземпляры планов `models` создаются в коммите и никогда в рендере (D188): первый
+  проход вклада не рендерит ничего, layout-эффект с ключом по идентичности вклада собирает монтирование из
+  закоммитившихся пропсов, а React сбрасывает этот один дополнительный синхронный рендер до отрисовки. Брошенный
+  рендер — вторая копия StrictMode, прерванный concurrent-проход, поддерево, приостановленное ленивым соседом, — не
+  создаёт ничего, поэтому подметать, усыновлять и пересобирать нечего, а layout-эффект ребёнка никогда не видит
+  закрытое монтирование.
+- **Структурные читатели.** `Readable`, `Resource` и источник спроса это структурные контракты, поэтому хост вправе
+  реализовать их объектом, члены которого — методы. Любой хук зовёт их через тот объект, который ему передали, и
+  никогда как оторванную функцию, поэтому адаптер вправе опираться на свой `this` (D199).
+- **Закреплённое монтирование.** Идентичность закоммиченного вклада владеет набором моделей. Повтор эффектов
+  StrictMode и скрытие/раскрытие Suspense используют тот же живой набор и состояние; отключение layout-эффектов
+  его не закрывает. Реальная замена идентичности или размонтирование освобождает его один раз. Размонтирование
+  скрытого поддерева освобождает набор в микрозадаче, потому что React уже отключил его layout-эффекты;
+  уведомления readable никогда не выполняются в insertion effects (D209). После освобождения вызов это отмена,
+  а не ошибка продукта.
+- **Один Call — одна команда.** У монтирования одна команда на различимый Call, сколько бы полей модели его ни
+  называли: два поля одной модели это алиасы, они делят запись, активацию и фенс (D197). Две модели одного
+  монтирования с одним id модели по-прежнему дубликат. Статус остаётся локальным для потребителя: `useCommand` и
+  каждый ключ `useCommands` держат свои `inFlight`, `result` и `lastError`, даже когда называют один Call.
+- **Ошибки.** Один класс на субъект авторского словаря, состояние в поле `code`: `FeatureError`, `CallError`,
+  `ReadableError`, `ContributionError`, `ApplicationError`, `DeclarationError`. Отмена это маркер по коду, а не
+  место в иерархии: он истинен для `CallError` с `cancelled` и `closed`, `FeatureError` с `retired` и
+  `ContributionError` с `inactive`. `CallError` с `unavailable` или `publication-rejected` такого бренда не несёт:
+  это ответ продукту, а не брошенный вызов. Тому же закону подчиняется `FeatureBoundaryError` с кодом `missing`: он
+  живёт в `@opetope/react/integration` вне бюджета трёх безопасных входов.
+- **Границы.** `@opetope/*` не импортирует хосты приложений, их адаптеры и UI-дизайн-системы. Production-файл в `@opetope/*/src` не
+  больше 600 строк. На hot path методы вызываются напрямую, без `Reflect.apply`, bind-обёрток и массивов аргументов;
+  успешный путь не создаёт `Error`, циклы не добавляют защитный freeze. Новые per-operation записи требуют
+  точечного измерения аллокаций в пределах бюджетов. Hostile-boundary валидация выполняется на входе внешних данных.
+
+---
+
+Повторный вход из callbacks сохраняет эти законы (D218): close приложения фенсит готовых участников ещё открывающейся
+condition group, включая member, вернувшийся после close. Abort/getter/key callbacks ресурса не могут затереть новую
+selection или восстановить состояние после fence. Latest admission резервирует waiter и место в lane до уведомлений
+о замещении; reentrant close/retire завершает этого waiter. Физический cleanup сохраняет порядок зависимостей.
+
+Выбор target потока следует тому же правилу актуальности (D219): если getter источника или key callback синхронно
+вызывает новую selection, прежний callback не может заменить её после возврата. Актуальность selection отделена
+от равенства request key: новый target с тем же ключом остаётся доступен следующему refresh.
+
+## 5. Гейты и бюджеты
+
+Бюджеты производительности и размера — ratchet: повышением предела нельзя скрывать регрессию. Добавление
+публичного слова в пределах цели требует явного решения и compile-checked пилота приложения; гейт фиксирует
+согласованное изменение, как для D187 и D207.
+
+### 5.1 `ci:public-surface`
+
+Считает авторский словарь трёх безопасных входов — `opetope/core/src/index.ts`, `opetope/runtime/src/index.ts`,
+`opetope/react/src/index.ts` — при текущем бюджете из
+[контракт публичной поверхности](spec.ru.md#5-гейты-и-бюджеты), итогах и целях §3. Имена дедуплицируются по
+входам, поэтому re-export ничего не стоит.
+
+Тот же гейт держит ещё четыре проверки на внутренних входах `core/src/internal.ts`, `runtime/src/internal.ts`,
+`react/src/integration.ts` и `react/src/testing.tsx`:
+
+| Проверка                | Что валит гейт                                                                                                                                                                          |
+| ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Изъятые слова           | `[Tt]ask[A-Z]`, `^Task$`, `[Ss]ignal[A-Z]`, `Domain[A-Z]`, `^Domain`, `View[A-Z]`, `^Setup[A-Z]` в любой позиции идентификатора на внутреннем входе                                     |
+| Утечки в подписях       | публичное значение, чей возвращаемый тип называет internal-only тип, вне allowlist из трёх входов (`onDemand`, `optional`, `selectByKey`)                                               |
+| Kernel-слова в глубине  | обход глубины 4 по свойствам и результатам вызова каждого публичного типа, отказ на `Module`, `Attachment`, `Executor`, `Authority`, `Owner`, `Blueprint`, `IR`                         |
+| Тексты авторских ошибок | строка или template literal, доезжающая до класса авторской ошибки и называющая module, attachment, executor, authority, owner, blueprint, generation, lifetime, task, setup или domain |
+
+Классы авторских ошибок это `ApplicationError`, `CallError`, `ContributionError`, `DeclarationError`,
+`FeatureError`, `ReadableError`.
+
+### 5.2 `ci:size-limit`
+
+Бюджетов пять, и все пять меряют то, что видит автор. Фикстуры это собранные consumer-ы, а не пакеты целиком, кроме
+`@opetope/react`, который меряется на `dist`.
+
+| Бюджет                       | Пакет              | Предел |
+| ---------------------------- | ------------------ | ------ |
+| `author primitives consumer` | `@opetope/core`    | 1.1 кБ |
+| `data layer consumer`        | `@opetope/core`    | 4.9 кБ |
+| `public feature consumer`    | `@opetope/runtime` | 32 кБ  |
+| `application graph consumer` | `@opetope/runtime` | 48 кБ  |
+| `dist/**/*.js`               | `@opetope/react`   | 18 кБ  |
+
+Фикстура `feature-consumer.ts` держит текущую форму: условие в `when`, слабый импорт и слабый порт через `optional`,
+живые `exports`, вклады `port`, `register` и `pipe`. `public feature consumer` определяется самим фичевым рантаймом, а не богатством композиции фикстуры: минимальная возможная фича — один host-контракт, один `calls`, один `openFeature` — весит уже большую часть бюджета, а снятие `resource`, `model`, `port` или `register` меняет вес на десятки байт, потому что граф фичевого рантайма почти монолитен.
+
+npm-артефакты используют минифицированный ESM с `keepNames: false`, сохраняют декларации `.d.ts` и поставляют source
+maps с исходным TypeScript в `sourcesContent` (D254). Имена функций и конструкторов, полученные через рефлексию, не
+являются стабильным API; явные ID деклараций, публичные имена/коды ошибок и идентичность для `instanceof` сохраняются.
+Карты помогают перейти к исходнику и раскрывают реализацию. Меньший несжатый JavaScript не гарантирует меньший
+tarball или итоговый бандл приложения; см. [содержимое пакетов](releases.ru.md#содержимое-пакетов).
+
+### 5.3 Проверка сборки приложения
+
+Бюджеты бандла приложения и размещение чанков принадлежат хосту-потребителю. Когда приложение динамически
+загружает манифест или UI фичи, проверка его сборки подтверждает наличие ожидаемых чанков и отсутствие кода,
+предназначенного для отложенной загрузки, в initial-чанках страниц. Сам по себе dynamic import в исходнике не доказывает, что собранный бандл сохраняет эту
+границу. Size-фикстуры пакетов измеряют потребителей фреймворка; хост дополнительно измеряет полный бандл
+своего приложения.
+
+### 5.4 `ci:perf-memory`
+
+Гоняет нагрузки на размерах 1, 100 и 10 000 (application: 1, 100 и 1 000) против
+`perf-memory-budgets.json`, schema 11. Гейт проверяет схему reference baseline; числовой enforcement использует
+абсолютные пределы и scaling guards внутри текущего прогона, а не сравнение с историческими таймингами baseline.
+Требуется Node `--expose-gc`.
+
+Каждая нагрузка и размер проходят один полный прогрев, три замера времени и три отдельных замера памяти.
+`results.*.*.durationMs` — медиана wall time полного workload: setup harness, ожидание cleanup и естественный GC
+остаются внутри окна. Колбэки sampling heap и измерительного harness в timing-проходах ничего не делают;
+принудительная сборка перед каждым проходом завершается до старта часов. Время обвязки не вычитается из смешанного
+замера. Memory-проходы сохраняют sampling после GC, baseline после открытия harness и финальную сборку после cleanup;
+peak-live и retained memory берутся по максимуму трёх проходов. `timingSamples` и `memorySamples` сохраняют все
+результаты, включая `instrumentedDurationMs` и счётчики проб. У каждого прохода должен быть конечный checksum,
+совпадающий с прогревом, и валидные измерения; ошибка завершает гейт без повторов до прохождения.
+
+Schema 11 заменяет смешанную методику D252. Пределы 500 мс для command и 1 200 мс для application, остальные
+численные бюджеты, размеры и тела нагрузок не меняются. Старые тайминги schema 10 несопоставимы;
+полный reference переснимается явно. Уменьшение времени после удаления проб не является ускорением runtime.
+Разделение относится к `results`; отдельные allocation, adapter, graph и listener workloads сохраняют свои
+документированные методы измерения (D253).
+
+`allocationRate.*.estimatedAllocatedBytesPerOperation` использует Poisson sampling V8 со средним интервалом
+16 384 байта, включая объекты, собранные minor и major GC. Это медиана трёх прогонов с измерительной обвязкой,
+без external backing stores; оценка, а не точный учёт. При нуле samples гейт проверяет 95%-ную верхнюю границу
+`-log(0.05) * samplingInterval / operations`. GC observer ждёт два оборота event loop и фильтрует записи по окну
+нагрузки; калибровка на 500 000 объектов проверяет собранные аллокации независимо от retained heap.
+`peakLiveBytesPerOperation` измеряет живой heap после GC, а не allocation rate. Baseline пишется только после
+успешного enforcement (D172).
+
+Насыщенная CallLane использует production-очередь с 1k, 10k и 100k ожидающих запросов. Она проверяет FIFO-дренаж
+и произвольную отмену чередующихся внутренних записей; enqueue измеряется отдельно от drain/cancel, берётся
+медиана пяти прогонов и проверяется рост цены операции. Браузерная проверка отдельно создаёт настоящее ребро
+приложения и блокирует уборку потребителя, доказывая, что его провайдер остаётся физически открыт.
+
+`applicationGraphCompile` отдельно измеряет `defineApplication` на цепочке, звезде, графе групп и независимых
+фичах при 256, 1 024 и 4 096 фичах. Определения строятся вне измерения; после двух прогревов идут семь samples.
+У каждой формы потолок 100 мс на 4 096 фичах и guard роста цены на фичу 3× с нижней границей времени 1 мс.
+Дополнение schema 9 измеряет компиляцию приложения, сохраняя измерение аллокаций и прежние лимиты (D213).
+
+`hotPathScaling` добавляет batch/append/withdraw в одном target вкладов при 2k/4k/8k/16k entries,
+чередующиеся admission `latest` и контрольный `queue` за заблокированной общей lane при 1k/2k/4k/8k парах,
+а также idle-чтение inspection при 256/1 024/4 096 фичах: без импортов и с host-import у каждой фичи.
+Итог — медиана пяти samples после двух прогревов, без setup, forced GC и cleanup.
+Проверяются результат публикации, блокировка исполнения, уборка и неизменный sequence idle-инспекции.
+У каждой формы абсолютный потолок на наибольшем размере и guard роста цены операции 3× с нижней
+границей 1 мс для малого размера (D245).
+Гейт требует все заявленные размеры, ровно пять конечных samples на строку и соответствие записанной медианы.
+
+Perf- и TypeScript-гейты до нагрузок проверяют все обязательные числовые поля бюджетов по независимой схеме.
+Отсутствующие и неизвестные ключи, нечисловые, отрицательные и не конечные пределы вызывают отказ;
+enforced-сравнения также отвергают отсутствие измерения. При `--enforce --write-baseline` неуспешный вердикт
+оставляет прежний baseline; успешный отчёт заменяет его атомарно. `ci:gate-config` проверяет эти ошибочные пути (D245).
+
+Ключи бюджетов и форма каждой группы:
+
+| Группа                    | Ключи                                                                                                                                                          |
+| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `workloads`               | `command`, `definitionCompile`, `reusedDefinitionLifecycle`, `contribution` — у каждого `durationMsAt10k`, `peakLiveBytesPerOperationAt10k`, `retainedMbAt10k` |
+| `applicationGraphCompile` | цепочка, звезда, граф групп и независимые фичи: `medianMsAt4096` 100, `perFeatureGrowthFactor` 3                                                               |
+| `hotPathScaling`          | каждая из семи форм: `medianMsAtLargest` 50 для вкладов, 150 для admission/inspection; `perOperationGrowthFactor` 3                                            |
+| `listenerMultiplicity`    | `contributionDurationMsAt10k` 3 000, `callDurationMsAt10k` 3 000, `peakLiveBytesPerOperationAt10k` 32 768, `retainedMbAfterUnmountAt10k` 14.5                  |
+| `coreData`                | `graph`, `leaseChurn`, `settledRead` — у последнего `microsecondsPerReadAtDepth1000` 1 и `depthGrowthFactor` 3                                                 |
+| `allocationRate`          | `command` 5 120, `contribution` 3 072 байта на операцию на 10 к, `unobservedWrite` 8 байт на операцию на 100 к                                                 |
+| `adapterDepth`            | режимы `syncPrimitive`, `plainObject`, `nativePromise`, `customThenable`, `neverSettlingCancel`                                                                |
+| `lifecycleStepDepth`      | `sync` и `async`, у каждого открытие, закрытие, байты на шаг и удержанные МБ на 1 000                                                                          |
+| группы одной формы        | `cleanupRetry`, `coldInternalImport`, `mailbox`, `readableSelector`                                                                                            |
+
+`workloads.contribution` публикует и снимает 10 000 вкладов под бюджетом 1 000 мс полного workload без проб памяти и 16 384 peak-live байта на операцию;
+`workloads.command` держит 2 048 peak-live байт на операцию на 10 к. `listenerMultiplicity` проверяет контракт слушателей: у контроллера вызова нет членов подписки (`getSnapshot`/`subscribe` отсутствуют, остались ровно `activate`, `close`, `diagnostics`, `run` — команду вызывают, а не наблюдают, см. decisions.md, D162), у смонтированного `useReadable` ровно один listener на его `Readable`, после размонтирования ноль. `coreData.settledRead` читает активную чистую цепочку
+20 000 раз на глубинах 1, 100 и 1 000 под двумя бюджетами: одна микросекунда на чтение на глубине 1 000 и рост не
+больше 3× между глубинами 1 и 1 000.
+
+### 5.5 `ci:type-stress`
+
+Компилирует три сгенерированные фикстуры — `large-feature-01`, `-20`, `-40` — с `--extendedDiagnostics` и опрашивает
+на каждой языковую службу. Schema version 4; гейт сравнивает с baseline той же схемы, а
+`type-stress-budgets.json` на каждом срезе называет, какие числа `enforced`, а какие `informational`.
+
+| Enforced budget                |     01 |     20 |      40 |
+| ------------------------------ | -----: | -----: | ------: |
+| `tscInstantiations`            | 10 000 | 80 000 | 155 000 |
+| `tscMemoryMb`                  |    160 |    220 |     260 |
+| `ideRssMb`                     |    400 |    600 |     650 |
+| `ideDiagnosticMaxCount`        |      4 |      4 |       4 |
+| `ideDiagnosticMaxLineDistance` |     30 |     30 |      30 |
+
+| Informational reference  |  01 |  20 |    40 |
+| ------------------------ | --: | --: | ----: |
+| `tscCheckMs`             | 150 | 350 |   550 |
+| `tscTotalMs`             | 500 | 800 | 1 000 |
+| `ideColdCompletionMs`    | 300 | 350 |   400 |
+| `ideWarmCompletionP95Ms` |  10 |  10 |    12 |
+| `ideQuickInfoP95Ms`      |  10 |  10 |    12 |
+| `ideDiagnosticMs`        |  60 | 200 |   400 |
+
+**Правило таймингов (D224):** каждая миллисекунда этого гейта информационна. Она печатается как
+`actual of reference` и ничего не останавливает, включая два временных ratchet — время проверки против удвоенного
+записанного baseline и время проверки на 40 секциях против max(2.75 × время проверки на 20 секциях, 1 000 мс), —
+потому что на загруженной машине та же фикстура качается вокруг них без единой правки строки. Гейт держит то, что
+решает сам код: instantiations по таблице и по `1.15 ×` записанного baseline, память компилятора, RSS языковой
+службы, форму каскада диагностик и объявленную поверхность среза против baseline, с которого она записана.
+
+### 5.6 `ci:browser-floor`
+
+Два прохода по production-исходникам `core`, `runtime` и `react`, без тестов. Объявленный пол это Chrome 82,
+Firefox 110, Safari 15, iOS 15, Android 82.
+
+Проход по поверхности сопоставляет каждое обращение к члену, каждый глобальный конструктор и каждую глобальную
+функцию с lib-декларациями TypeScript и отказывает всему, что выше пола, — `Object.hasOwn`, `Promise.any`, добавкам
+`AbortSignal`, `AbortController.abort(reason)`, `String.prototype.at`/`replaceAll`, новым методам массива,
+`Error.cause`, `Error(options)`, `AggregateError`, `FinalizationRegistry`, `WeakRef` — вне двух проверенных
+исключений: `core/src/abort-compat.ts` для abort-хелперов и `core/src/platform-compat.ts` для `AggregateError`.
+
+Проход по сырому dist трансформирует каждый выпущенный `.js` esbuild-ом с целями `chrome82`, `firefox110` и
+`safari15` и падает на первом байте, где трансформация расходится с отгружаемым выводом.
+
+### 5.7 `ci:inspection`
+
+Граница наблюдения проверяет `ringCapacity` как неотрицательное безопасное целое до подключения (по умолчанию 256;
+ноль сохраняет снимки, но не историю delta). Диагностические id приложений используют namespace `application:`,
+поэтому одинаковые id объявлений приложения и фичи не сливаются. Необязательный `cause.at` — неотрицательное целое
+в домене Date, не больше `8_640_000_000_000_000` миллисекунд эпохи. Замена activity является изменением кадра,
+даже когда graph operations пусты (D242).
+
+Гоняет исполняемую приёмку `assertInspectionSessionContract` из `@opetope/devtools/testing` против настоящего
+продюсера `@opetope/runtime`, на фикстуре приложения с фичей-провайдером, фичей-потребителем со слабым импортом,
+слабым портом, жёстким портом и вкладом `pipe`, и одним условием, привязанным хостом. Корпус это настоящие
+транзакции: смена условия единственная, которую рантайм коммитит синхронно, поэтому синхронная приёмка видит именно
+её, а всё остальное успевает лечь. Ровно одна проверка имеет право быть помеченной `skipped` — resync выпавшего
+кадра, который харнесс уронить не умеет и который закрывает собственный тест кольца в рантайме. Второй пропуск валит
+гейт. После приёмки фикстура на своём харнессе проверяет два факта D167: переключает `when` одного вклада
+туда-обратно и ждёт `withheld` и обратно `published`, затем закрывает приложение при живых экземплярах и ждёт, что не
+осталось ни живого экземпляра, ни живого вклада, а группа закрыта. Гейт валит любая упавшая проверка, а не только
+второй пропуск. Затем гейт прогоняет порт управления D176 на живой группе с зависимым: suspend обязан примениться,
+показать `force-inactive` у группы и увести зависимого, resume — снять и то и другое, неизвестное условие и здоровый
+экземпляр — получить отказ данными, а `close()` — снять override. Гейт живёт в `tooling/stress`, чтобы рантайм не
+держал зависимости на devtools; единственное ребро в обратную сторону это шов подключения devtools, который
+открывает оба порта за хоста (D248).
+
+### 5.8 `ci:docs` — ссылки на решения
+
+Каждый `Dnnn` в `opetope/**/src` и `tooling/stress/scripts/*.mjs` обязан разрешаться в
+заголовок `### Dnnn —` в `docs/decisions.md`. Именно это делает обещание архива — номера стабильны, существующие
+строки не редактируются — проверяемым, а не заявленным: номера нельзя двигать как раз потому, что на них ссылается
+код.
+
+Коды находок ревью (`L3-F17`, `R1-1`) в тех же исходниках запрещены; гейт проверяет формы `L<digits>-F<digits>`
+и `R<digits>-<digits>`. Они называют строку отчёта, которого у читателя кода
+нет; находка, которую стоит держать в комментарии, — это либо решение, и тогда она ссылается на него, либо
+рассуждение, и тогда оно написано словами. Проход сделан по всем пакетам, поэтому карта записанных чисел пуста, а
+код теперь просто ошибка, где бы он ни встретился.
+
+## Сценарные тесты и физическая активность
+
+`createScenario(application, options)` из `@opetope/react/testing` открывает настоящее приложение и его существующую
+inspection session (D206, D215). Передайте обычные `imports`/`conditions` и принадлежащий тесту адаптер
+`host.mount(Component)`, возвращающий handle с `unmount()`. Пакет не добавляет зависимость от DOM renderer или test runner.
+`scenario.mount(target, { props })` использует опубликованные Slot contributions и возвращает
+`{ host, updateProps, unmount }`; `host` — исходный результат renderer. Typed targets требуют `options.props`,
+а targets без props опускают его, как в `Slot` (D217). Fixtures не обходят authority команд.
+
+Синхронный конструктор возвращает `ready`, поэтому pending lazy body можно исследовать до готовности.
+`waitFor(snapshot => predicate, { label, timeoutMs, pollIntervalMs })` просыпается от inspection и дополнительно
+опрашивает predicates внешнего UI; `notify()` будит его после изменения управляемой fixture. По умолчанию deadline
+равен 1000ms, polling predicate — 10ms. `ScenarioTimeoutError` содержит data-only snapshot, ограниченную историю и
+наблюдаемые conditions, фазы feature, body load, lane blockers и удержания ресурсов. Причины внутри repository
+или сети не выводятся из догадок. `getSnapshot()` и `history()` используют ту же модель наблюдения; по умолчанию
+хранятся 64 снимка, activity ограничена 256 записями. Capacities — целые от 1 до 10000.
+Не заменяйте predicates фиксированным числом ticks.
+
+`close()` синхронно ставит fence admission приложения, размонтирует зарегистрированные экраны и ждёт их cleanup
+вместе с physical application drain. Deadline не отменяет cleanup: последующий `close()` может дождаться того же drain.
+Deadline готовности также оставляет приложение доступным для inspection и явного закрытия.
+`ownership()` описывает только зарегистрированное владение runtime; при отсутствующих, stale или усечённых данных
+возвращается `unknown`. Терминальный stale-снимок считается полным лишь после подтверждённого сценарием успешного
+физического cleanup. Это допускает проверку нулевых счётчиков в данном scope, но не доказывает отсутствие произвольных
+host/UI/GC-утечек. Успешный cleanup очищает imports приложения и внутренние ссылки на renderer. Promise отказавшего
+cleanup может удерживать исходные ошибки и retry capabilities; сохранённый пользователем `mounted.host` удерживает его renderer result.
+
+Inspection graph/frame имеют схему `/3` и optional snapshots `opetope.runtime-activity/1`. В пределах одной session
+frame без `activity` сохраняет предыдущую activity; полный snapshot/reset без этого поля очищает наблюдение (D216).
+Frame с `activity` заменяет предыдущую activity целиком.
+Используйте согласованные версии runtime/devtools: readers `/2` отвергают новую revision. Activity указывает execution,
+фактическое поколение feature, физические Calls, точных текущих lane blockers, зарегистрированные leases и попытки загрузок.
+Спрос хоста и UI-модели неизвестны; у stream наблюдается state, но не физические identities загрузок. `freshness`
+и `truncated` отличают полное live-наблюдение от усечённого или отключённого. Закрытая session имеет stale-снимок;
+`closed: true` требует успешного физического drain приложения. Control authority и продуктовые payload не добавляются.
+Размер activity ограничен capacity записей. Сбор снимка обходит зарегистрированных owners, executors и resources,
+поэтому capacity не ограничивает стоимость обхода. Сбор останавливается после доказанного truncation;
+idle executors могут требовать обхода, чтобы подтвердить полноту данных. Обычный call dispatch не создаёт диагностических записей при
+выключенном наблюдении. Frames ограничены существующей ring capacity.