@opetope/react 0.12.0 → 0.12.1

package/CHANGELOG.md

@@ -1,5 +1,149 @@
 # @opetope/react
 
+## 0.12.1
+
+### Patch Changes
+
+- 997137b: **Documentation only: four statements that had drifted from the tree are corrected, and the copies they drifted
+  out of are replaced by the one place each law is written (D460).** No source file changes, no public name moves,
+  no gate budget moves and no compiled example is edited. The root README gains a map, «Where each contract is
+  written once», naming for every subject the one normative section, the worked examples over it and nothing else.
+
+  - **The runtime word map promised two Resource names and the entry publishes nineteen.** `Resource` and
+    `ResourceState` were described as «the two words this entry publishes for a materialization», with the rest of
+    the family «named from `@opetope/core`». The entry re-exports the family whole — every `Resource*` word plus
+    `EventDelivery`, `LiveDelivery`, `PaginationOutcome` and `PaginationState` — and the comment above that block
+    names the decision that made it so. The row now says what the file does, which is what lets a feature author
+    write one import line for a declaration and for the `ResourceData<Data>` its `apply.change` annotates.
+  - **`@opetope/core` said it stays `private`, and its manifest carries no such field.** The manifest has
+    `publishConfig.access: public` and no `private`. The sentence keeps what was true — the API is experimental
+    while the design is under review — and says what that costs an upgrader: an alpha removes a superseded name
+    instead of keeping it beside its replacement, so an upgrade is read through the release notes. It makes no claim
+    about what is or is not on npm today.
+  - **Three pages still taught the pre-`LostWrite` law.** The runtime README said a dropped write is lost «in
+    silence rather than thrown at the caller or recorded by the reporter»; the primitives reference said «nothing is
+    reported»; and the spec's own model-layer section said «dropped without a reporter record». The law changed two
+    decisions ago and the normative sections that state it — §2.11 and §4 «Failures after abort» — were already
+    right: the first write an authority loses after ending inside a write into a cell its source reads, its own or
+    one of a command it invoked, reaches the reporter as `LostWrite`, once per run, and every other drop is silent.
+    All three now say that and defer to §4 for which is which. `update` is still `void`: nothing here promises a
+    throw at the caller. The primitives tables that listed a dropped write as always silent are corrected with them.
+  - **Two code tuples had already lost codes, and both are replaced by a link.** The authoring guide listed the
+    codes of every error class and was missing two of the six of `ContributionError`; the core README's boundary
+    list was missing the `CancellationError` its own word map names one paragraph above. Which class carries which
+    code, and which codes are cancellations rather than product answers, is the spec's «Errors»; which class is
+    thrown by whom is the how-it-works error table. The React README's outcome bullet, a third copy of the same law
+    plus the spec's «Command outcomes», goes the same way.
+  - **The rule that looked stale is not, and its reason was.** The authoring guide requires a result type on a model
+    factory, because an inline arrow handed straight to `openModel(Decl, ctx => …)` is not instantiated when its
+    body is checked. A probe over the current sources confirms the rule and refutes the explanation: a body that
+    names no input is inferred as `Command<void, void>`, taking the `void` default instead of the `never` the guide
+    claimed — so the declaration's input never arrives, a body that reads `input` is refused on the read with the
+    four-position instruction, and a body that reads nothing is refused against the record the factory returns. The
+    reason is rewritten to that; the rule stands.
+  - **The repetitions removed, and what was left in their place.** The primitives reference's shared-laws section
+    stated the fence-and-drain, writer, cancellation and reporter laws in full while declaring the spec normative
+    for all four; it now states what a primitive owes each law and links. The runtime README restated the reason
+    behind `opetope/no-snapshot-in-update`, which that rule's own README writes out, and restated the model
+    context's lanes and its `invoke`-from-an-effect verbatim from the core README, which declares them. Each task
+    page keeps its short explanation and its warnings.
+
+- 8aec982: **A command's one waiting place is written as the record that names it: `concurrency: { pending: 'latest' }`
+  (D459).** The scalar `concurrency: 'latest'` named the input that wins and never named what it wins — «the latest»
+  reads as a place in a queue, as the body already running and as a cached answer, and only the first was true. The
+  shared form of the same fact never had that gap: `{ lane, pending: 'latest' }` says the place out loud, with the
+  `pending` an event and a live Resource already write for their own one waiting place. One fact was being written in
+  two vocabularies, and the shorter one left out the part that mattered. The word is removed rather than kept beside
+  the record, which makes this a breaking change to the authoring surface of a model command, of a model selection
+  and of a feature command.
+
+  - **Migrate by writing the place.** `concurrency: 'latest'` becomes `concurrency: { pending: 'latest' }` in
+    `ctx.command`, `ctx.select` and `own.command`. `concurrency: { lane, pending: 'latest' }` is unchanged: the lane
+    is the one parameter this record takes, and it is optional now instead of required. Nothing else about the option
+    moves — the same record, the same siblings, the same `dedupe` prohibition beside it.
+  - **No law moved with the spelling.** While call 1 runs, calls 2 and 3 take one waiting place: the body of 2 never
+    starts, its wait ends as `CommandError('cancelled', 'Command <id> replaced a waiting input.')`, and 3 runs when 1
+    finishes. A newer request never reaches the call in flight. The regression that holds this reads `signal.aborted`
+    inside the running body — after both newer requests were admitted and before the body returns — rather than
+    counting abort events, because the abort that follows a call's own end belongs to its cleanup and says nothing
+    about the policy. It was proved by substitution: with the kernel changed to cancel whatever is in flight, the
+    test fails on that line.
+  - **The retired word is answered with its replacement, not with a list of everything else.** The runtime throws
+    `Model command concurrency latest is now a record: write { pending: 'latest' }, or { lane, pending: 'latest' }.`
+    — and `Model select`, `Feature command` the same. Two neighbouring messages move with it: the choice sentence
+    loses the word — `concurrency must be queue, parallel, a lane of this surface or a record.` — and the record's own
+    refusal now says the lane is optional. A record that names `lane` and hands it `undefined` is still refused, by
+    the type under `exactOptionalPropertyTypes` and by the runtime, which reads the shape of the record by its keys.
+  - **The compiler names the replacement too, because the literal stays in the union.** The options record of a
+    command gained a third member — the retired word beside a key an author cannot write — so a refusal arrives as a
+    missing property carrying the instruction. Without it the union held no string at all, every word written there
+    widened to `string`, and one sentence answered a typo and a retired word alike. What the two now print, the same
+    on a model and on a feature: `{ concurrency: 'quee' }` is a `TS2820` that names the word and suggests `'queue'`,
+    which is better than it was before this change, and `{ concurrency: 'latest' }` is a `TS2345` whose elaboration
+    carries «`concurrency: "latest"` is now a record: write `{ pending: "latest" }`, or `{ lane, pending: "latest" }`».
+    A selection is the one surface where the compiler names the word written and not its replacement — its options
+    record is not a union — and there the runtime and the lint rule carry it.
+  - **`opetope/no-retired-vocabulary` reports it.** `concurrency: 'latest'` is a retired _value_ of a live key, the
+    shape `overflow: 'reject'` already had, so the rule now reads the values of a command's options record as well as
+    its keys and reports on the word that was written. A project that pins the rule's output by its own fixtures gains
+    one row.
+  - **What the gates read.** Instantiations are unchanged — 11 756, 87 710 and 160 268 against ceilings of 12 200,
+    99 062 and 181 237 — because a scalar became a record that already existed. The tightest size row, the headless
+    session consumer of `@opetope/devtools`, stays at 6.95 kB of 7.1 kB. The two runtime rows carry the new branch and
+    its message: the application graph consumer moves 48.56 → 48.66 kB of 49 kB and the public feature consumer
+    39.88 → 39.92 kB of 41 kB, measured by rebuilding the validator both ways. No budget moves.
+
+- 4e65393: **The published archive of every package loses `README.ru.md`, and `@opetope/runtime` loses the Russian pages of
+  its `docs/` as well (D456).** The Russian half of the documentation is removed: nineteen `*.ru.md` files,
+  **2 027 997 bytes**, which is 39.0 % of what `ci:docs` counts as a document and 35.1 % of every `*.md` in the tree.
+  Documentation is written once, in English, from here on. No public name, no `exports` entry and no subpath moves —
+  a `.ru.md` was never a resolvable specifier, only a file read by its path — and no line of shipped JavaScript
+  changes, which is why this is a patch. The composition of what is published does change, and this is the line that
+  says so.
+
+  - **What goes.** `CONTRIBUTING.ru.md`, `README.ru.md`, the README of the minimal React example, the nine guides of
+    `docs/` — agent guide, cookbook, devtools, how-it-works, primitives, releases, both migration guides and the
+    spec — and the `README.ru.md` of all seven packages. `docs/decisions.md` stays Russian and keeps no pair, as it
+    never had one. The nine copies under `packages/runtime/docs/` are generated by packaging and leave on their own.
+  - **The rule that required a pair is cancelled, with its gate.** `CLAUDE.md` said «README and user guides have
+    English/Russian pairs, updated together» with four exceptions; it now says a document is written once, in
+    English, and gets no second copy. `ci:docs` no longer looks for a `*.ru.md` beside a document and no longer
+    compares the heading skeleton of a pair, and its report reads «links and example section order passed».
+  - **One gate is lost outright, and nothing replaces it.** The fixture generator held every English example against
+    its Russian twin as the same program — syntax without comments and without JSX text — which is how D441 caught a
+    real drift in a spec §2 block, a string literal that differed in one copy. The defect class that stops being
+    caught is a silent edit to a detail of an example that still compiles: a string literal, a number, the order of
+    two arguments of the same type. `ci:type` accepts any literal of the right type, `ci:docs` reads section order
+    and links rather than values, `ci:asserted-refusals` holds pragmas, and the generator's own `--check` compares a
+    fixture with the very document it was lifted from, so one `fixtures:generate` makes any such edit the new
+    baseline. The twin was the only place in this repository where one program was written twice and the two
+    writings were compared. It also never knew which copy was right — in the one case it fired, the wrong copy was
+    the Russian one — and it protected above all the copy that nothing compiled.
+  - **Where the archive change is written down, so it cannot drift from its gate.** The composition of an archive is
+    stated in six places and all six are rewritten: the `files` of the seven manifests; the required-file list and
+    the archive-member allowlist of the pack archive check; the fixture of that check's own unit test; the
+    allowlists of the two real pack smoke tests; and what packaging demands of each package before it packs. The
+    requirement that `@opetope/runtime` ship `docs/spec.ru.md` is gone; `docs/spec.md` is required exactly as before.
+  - **The numbers the gates print.** `ci:docs` reads 28 documents instead of 46 — nineteen leave and this changeset
+    is itself a document — with 4 pending changesets instead of 3 and 424 decision identifiers instead of 423. Its
+    feature examples halve, 64 to 32: that gate lints every fenced example that declares a feature, and it was
+    linting both copies of each one. Packaging prepares 10 documents instead of 19, and the merge-marker scan reads
+    1101 text files instead of 1117 — seventeen of the nineteen removed files live under a scanned root, and this
+    changeset is one file back. The document examples do not move at all: 38 spec §2 blocks and 132 blocks of 11
+    other documents, 2 fragments, 14 asserted refusals, exactly as before, because only the English block was ever
+    lifted into a fixture.
+
+- Updated dependencies [997137b]
+- Updated dependencies [ba75469]
+- Updated dependencies [d09568e]
+- Updated dependencies [8aa4d85]
+- Updated dependencies [8aec982]
+- Updated dependencies [be0613e]
+- Updated dependencies [4e65393]
+- Updated dependencies [e12b0b6]
+  - @opetope/core@0.12.1
+  - @opetope/runtime@0.12.1
+
 ## 0.12.0
 
 ### Minor Changes

package/README.md

@@ -1,21 +1,24 @@
 # `@opetope/react`
 
-The React binding for Opetope models and UI contributions. [The specification](../runtime/docs/spec.md) §3 sets the package vocabulary.
+React hooks and slots for Opetope models. A contribution grants the models its UI may read; hooks subscribe to selected data and expose commands with local status.
 
 ## Installation
 
 ```sh
-npm install @opetope/core @opetope/runtime @opetope/react 'react@^19.0.0' 'react-dom@^19.0.0'
+npm install --save-exact @opetope/core @opetope/runtime @opetope/react 'react@^19' 'react-dom@^19'
 ```
 
-Use matching Opetope versions. For release candidates, append `@next` to every `@opetope/*` package in the command.
-The API is ESM-only; Node 20.19+ is required. Development check commands below apply to a contributor checkout.
+Use matching exact Opetope versions; for release candidates, install every Opetope package from `@next`.
+Packages are ESM-only and support Node 20.19+. React integrations support React and React DOM 19.
 
-The normative EN/RU guides are shipped in `@opetope/runtime`: after installing it, open
-`node_modules/@opetope/runtime/docs/spec.md` or `spec.ru.md`; recipes are in `cookbook.md` and `cookbook.ru.md`.
-No GitHub access is needed to read those installed guides.
+## Example
 
-## Hello UI
+This focused example shows the package boundary. [Start](../runtime/docs/start.md) includes a complete
+feature, host, React entry and cleanup in one visible module.
+
+<!--example id="doc-readme-react-0"
+/* … */
+-->
 
 ```tsx
 import { defineModel } from '@opetope/core';
@@ -49,404 +52,42 @@ function CounterArea() {
 }
 ```
 
-A component gets neither a service, nor a class, nor a runtime ref. The contribution mount grants its feature's `own` models implicitly; the component or hook that reads a per-mount
-model declares it with `requiresModels`. `useModel` reads exactly that authority frame. `useCommand` returns
-`{ run, inFlight, outcome }` and always resolves the outcome, so a normal cancellation never becomes an unhandled
-rejection (D116, D292).
-
-`outcome` is the last settled non-cancelled outcome of this consumer: `ok` takes the place of a previous `failed`
-and a `failed` the place of a previous `ok`, a `cancelled` outcome moves nothing, and starting a run clears nothing,
-so a failure stays readable while the retry is in flight. Before the first settle it is `undefined`. Read it through
-its discriminant — `outcome?.kind === 'failed' ? outcome.error : null`.
-
-A command without input binds to an event through an arrow: `onClick={() => void logout.run()}`. The arrow is what
-keeps the React event out of the Command and the promise from hanging; `onClick={logout.run}` does not compile, because
-a `MouseEvent` is not a `void` input. Use `run(input, options?)` for data, an outcome, callbacks or a per-run signal.
-Where a lint config bans an inline arrow prop (`react-perf/jsx-no-new-function-as-prop`, `react/jsx-no-bind`), hoist
-it with `useCallback(() => void logout.run(), [logout.run])`: the dependency is `run`, never the hook object (D290).
-
-`run` is stable while the invoker stays the same; the returned object is a snapshot of the render it was read in and
-changes as `inFlight` or `outcome` changes, so an effect or a memo depends on `run` and never on the hook — the rule
-`opetope/no-command-in-deps` holds this for the author (D290). A `run` captured from a replaced or unmounted
-consumer is fenced; it does not start work on the replacement.
-
-The hook schedules nothing. Every `run` reaches the command, and the order the command was declared with decides
-what happens to it (D203). For an absolute value setter the model declares `concurrency: 'latest'` in
-`context.command`, and the newest input then replaces the waiting one there (D185, D387). What the consumer keeps
-is its own: an already-aborted input signal is refused as `cancelled` without reaching the command, a run of an
-unmounted consumer is refused the same way, `inFlight` is true while any run this consumer started is unsettled,
-and every run carries its own callbacks and signal.
-
-To share equivalent pending or running work, the model declares `dedupe: true` or `dedupe: input => key`
-on `context.command`. Sharing keeps the first input and each caller's independent cancellation; neither form may
-be combined with `latest` (D277). These are Command options, not hook options.
-
-For several commands a component writes `useCommand` per command, or one `useModel` selection, which already
-answers ready hooks. `useCommands` is gone: a record over the one `CommandHook` was sugar that saved hook calls,
-not a second mechanism, and the set that is really wanted is a selection in the model, where `ctx.select` gives it
-an owner and a lifetime (D388).
-
-Two aliases of one Command have independent local statuses, just like two `useCommand` consumers; they use the same
-Command concurrency and mount command record (D197, D203). A selection introduces no shared busy state, queue or
-transaction; controls that overwrite one value still need one semantic command.
-
-## Selecting data and commands
-
-`useModel(Declaration, (model, { read }) => ({ ... }))` combines explicit data selection and command consumers (D205, D214).
-
-A model selection can use a named interface without an index signature (D217). Its result is a flat data record;
-arrays, functions, constructors and built-in collection/date/promise objects are not selection records.
-`read(source)` returns its snapshot; `read(source, project)` returns a projection. Authentic Commands selected as
-record fields become the same `CommandHook` as `useCommand`, including independent alias statuses and stable `.run`.
-A single selected command needs no nested hooks:
-
-<!--example
-import type { Command } from '@opetope/core';
-import { defineModel } from '@opetope/core';
-import { useModel } from '@opetope/react';
-
-const AuthModel = defineModel<{ readonly logout: Command<void, void> }>('example.auth.model');
-
-const LogOutButton = () => {
-/* … */
-};
--->
-
-```tsx
-const { logout } = useModel(AuthModel, auth => ({ logout: auth.logout }));
-return (
-  <button disabled={logout.inFlight} onClick={() => void logout.run()}>
-    Log out
-  </button>
-);
-```
-
-The one-argument form still returns the granted model; individual hooks remain available.
-
-Only explicitly read sources are subscribed, once per distinct Readable in the selection. Returned data fields are
-compared with `Object.is`; select scalar fields, spread a projected record into the selection, or return stable
-references. A newly allocated nested object is a changed field. The callback is pure: no hooks, commands or side effects.
-A read or selector error reaches the nearest React error boundary. Changing the selected sources or command keys
-changes their subscriptions/consumers at commit; an abandoned render cannot replace committed authority.
-
-The hook neither creates a model nor acquires a feature. It leases exactly the resources its selection names as
-values — that field answers a `ResourceHook`, and one lease per Resource identity covers the mount even when two
-keys name one Resource (D321, D359) — and nothing else: a
-`read(resource.state)` leases nothing, and neither does the one-argument form. Combining hooks does not promise fewer
-source subscriptions or faster renders; a raw `useModel` import now also includes the selection implementation.
-There is no additional Command scheduler.
-
-## Application host
-
-The host opens a feature graph with `openApplication`. Ready features publish their UI contributions atomically;
-the ordinary `Slot` mounts them into consumer-owned targets:
-
-<!--example
-import { defineSlot, Slot } from '@opetope/react';
-
-const exampleFooterSlot = defineSlot('example.footer');
-const exampleSettingsSlot = defineSlot('example.settings');
-
-const ExampleShell = () => (
-  <>
-/* … */
-  </>
-);
--->
-
-```tsx
-<Slot target={exampleFooterSlot} />
-<Slot target={exampleSettingsSlot} />
-```
-
-The application owns feature lifetimes; each feature's UI mounts through its contributions.
-
-## Feature demand boundary
-
-<!--example
-import type { ReactNode } from 'react';
-import type { Resource } from '@opetope/core';
-import { defineSlot } from '@opetope/react';
-import type { FeatureDemandSource } from '@opetope/react/integration';
-
-type Tasks = Readonly<{ id: string }>;
-type ConfirmActionProps = Readonly<{ itemId: string; onConfirmed: () => void }>;
-
-declare const host: FeatureDemandSource<Readonly<{ exports: Readonly<{ tasks: Resource<Tasks, 'none'> }> }>>;
-declare const itemId: string;
-declare const onConfirmed: () => void;
-declare const children: ReactNode;
-declare const Spinner: () => null;
-declare const Failure: (props: Readonly<{ error: unknown; onRetry: () => void }>) => null;
-declare const TasksResourceLease: (props: Readonly<{ children: ReactNode; resource: Resource<Tasks, 'none'> }>) => null;
-
-const confirmActionContentSlot = defineSlot<ConfirmActionProps>('example.confirmAction.content');
--->
-
-```tsx
-import { Slot } from '@opetope/react';
-import { FeatureBoundary, useFeatureRetry } from '@opetope/react/integration';
-
-function Retry() {
-  return <button onClick={useFeatureRetry()}>Try again</button>;
-}
+## Documentation
 
-<FeatureBoundary demand={host} error={<Retry />} fallback={<Spinner />}>
-  <Slot props={{ itemId, onConfirmed }} target={confirmActionContentSlot} />
-</FeatureBoundary>;
+The [reference](../runtime/docs/reference/react.md) owns the detailed contract, options and failure semantics.
+[Guides](../runtime/docs/guides/index.md) show individual tasks. Documentation is shipped with
+`@opetope/runtime` in `docs/`, so an installed application can read it without access to this repository.
 
-// or with render callbacks, when the ready instance itself is needed (D177)
-<FeatureBoundary
-  demand={host}
-  error={({ error, retry }) => <Failure error={error} onRetry={retry} />}
-  fallback={<Spinner />}
->
-  {({ exports }) => <TasksResourceLease resource={exports.tasks}>{children}</TasksResourceLease>}
-</FeatureBoundary>;
-```
-
-`FeatureBoundary` consumes a `FeatureDemandSource` supplied by host integration. It holds the demand for the feature,
-shows the ready branch once that demand is ready and isolates `useFeatureRetry` inside the error subtree. A branch may be a node or a
-render callback: the callback of `children` receives the ready instance typed by the demand, the callback of `error`
-receives `{ error, retry }`, and only the branch that is shown runs. The callback needs no `useFeature` of its own,
-so a ready consumer does not acquire the demand a second time; hooks still live in child components, not in the
-callback. There is no separate hook for
-reading the error: the host passed it into `error` itself, so it knows it without a second word (D142). UI enters a feature through `Slot`: there is no
-root, no `ui` section and no second binding API any more (D85).
-
-Both the boundary and the bare `useFeature` are exercised by the packaged consumer of `ci:pack`, which checks the
-law they share: one lease per mount, kept across a settled `retry` and released on unmount. `useFeature` is the
-hook half used where a host renders the readiness itself, and it is a candidate to leave this entry until a second
-application is measured; `FeatureBoundary` is not a pair with `ContributionBoundary` and stays (D301).
-
-## Contributions
-
-```tsx
-import { defineSlot, defineSwitchSlot, Slot } from '@opetope/react';
-
-const HeaderEnd = defineSlot<{ readonly mode: 'desktop' | 'phone' }>('example.headerEnd');
-const PageEnd = defineSwitchSlot<'home' | 'wallet', { readonly compact: boolean }>('example.pageEnd');
-
-function Header({ mode }: { readonly mode: 'desktop' | 'phone' }) {
-  return <Slot props={{ mode }} target={HeaderEnd} />;
-}
-
-function HomePageEnd() {
-  return <Slot props={{ compact: true }} target={PageEnd('home')} />;
-}
-```
-
-`defineSlot` creates an authentic target with an ordered set of contributions; `defineSwitchSlot` lazily creates and
-caches a stable target per route. `Slot` reads the atomic snapshot and renders every `{ Component }` in the authority
-frame of the instance that gave the contribution. The order and the stable key come from the contribution entries of the core, so
-React introduces neither a second comparator nor a second lifetime registry. The packaged consumer of `ci:pack`
-exercises that caching and routes one contribution through it (D301).
-
-`useResource(resource)` answers `{ pagination, refresh, reset, retry, state }`: the `ResourceState` through
-`useSyncExternalStore`, the lease `resource.acquire()` answers taken in a commit effect for as long as the component
-is mounted, and the three verbs as ordinary `CommandHook` consumers (D359). An interrupted render therefore opens
-nothing, and when the reference changes the state follows the new Resource while the effect cleanup releases the
-previous lease. The number of React hooks does not depend on the Resource: a declaration without `pagination`
-subscribes to a constant source and keeps a `loadNext` that answers `skipped`, while a declaration that carried the
-capability answers `pagination` as `{ loadNext, state }` (D356). A field of a `useModel` selection whose value is a
-Resource answers the same hook and takes the same lease, so a model declares no `Command<void, void>` around
-`resource.refresh()` to give a button its `inFlight`. `useReadable(resource)` is a compile error, because a Resource
-is not a `Readable`; `useReadable(resource.state)` and a `read(resource.state)` in a selector stay passive and lease
-nothing — observing and holding are independent questions, so a selector that reads the state and a `useResource`
-beside it subscribe twice (D349). The compile-checked example of specification §2.13 shows both sides of that
-(D301, D321).
-
-`refresh.run()`, `retry.run()` and `reset.run()` reach the Resource, which is owned by the model that declared
-it: `inFlight` is true until the outcome of the operation settles, `outcome` carries that `ResourceOperationOutcome`
-as the `value` of an `ok` status, and `run(undefined, { signal })` cancels the wait of this consumer and not the work
-the model owns. Two consumers of one Resource keep separate statuses, and `run` keeps its identity while the Resource
-does. A render that caught up with retirement renders the terminal record — `idle` with reason `retired` for a Resource
-a model owns, `unleased` for a feature's facade, which is a reference that outlives the instance — and unmounts,
-releasing its lease (D359, D364). Nothing here refuses a read because a lifetime ended: a source whose owner retired
-stops and keeps answering its last value, so `useReadable`, `useSelector` with an inline selector and a selection's
-`read` each read on and need no memory of their own. A refusal that remains is work that failed — a state that
-failed, a broken pagination cursor — and it still reaches the render.
-
-Direct component props, a contribution's `props` adapter and its model's props `Readable` share the same
-mount-owned snapshot. Incoming slot props publish in layout before paint, so direct and adapted renders cannot
-mix new props with an old model snapshot. Model factory failures clean up partially created kernels.
-Models belong to commit: an abandoned render creates no model to clean up (D170, D188).
-StrictMode effect replay and Suspense hide/reveal preserve the committed model bundle and state. Only actual
-identity replacement or unmount releases it; a hidden unmount releases in a microtask after React has disconnected
-the layout effects (D209).
-
-Demand retry is scoped to the source identity. Replacing a boundary's demand source allows its new retry to run
-even if the previous source's retry is still pending.
-
-Every mount is an error boundary of its own contribution (D256). A render or commit that throws stops there, is
-reported to the feature that published the contribution, and leaves the other mounts of the target untouched.
-`ContributionBoundary` states once, above every slot, what a failed mount shows:
-
-<!--example
-import { defineSlot, Slot } from '@opetope/react';
-
-declare const FailedContribution: (props: Readonly<{ error: unknown; onRetry: () => void }>) => null;
-
-const applicationSurface = defineSlot('example.surface');
--->
-
-```tsx
-import { ContributionBoundary } from '@opetope/react/integration';
-
-<ContributionBoundary error={({ error, retry }) => <FailedContribution error={error} onRetry={retry} />}>
-  <Slot target={applicationSurface} />
-</ContributionBoundary>;
-```
-
-`error` takes a node or a callback of `{ contribution, error, feature, retry, target }`, the failure shape of
-`FeatureBoundary` plus the identity of what failed: `contribution` is the published entry `<feature>.<provides key>`
-and `target` is the slot, so one branch can answer by surface. `retry` remounts the contribution, so its models are
-created again. The reporter of the publishing feature receives the same identity on a `ContributionError` whose
-`cause` is the original error, with code `render-failed` or `error-content-failed`. Without the provider a failed mount renders nothing — containment
-never depends on it. Error content that throws is contained the same way and reported, never escalated.
-
-## Scenario tests and physical activity
-
-`createScenario(application, options)` from `@opetope/react/testing` opens the real application and its existing
-inspection session (D206, D215). Supply the normal `imports`/`conditions` and a test-owned
-`host.mount(Component)` adapter returning an `unmount()` handle. The package adds no DOM renderer or test-runner
-dependency. `scenario.mount(target, { props })` uses the published Slot contributions and returns
-`{ host, updateProps, unmount }`; `host` is the renderer's original result. Typed targets require `options.props`,
-while targets without props omit it, exactly as with `Slot` (D217). Fixture commands do not bypass authority.
-
-As with `openApplication`, omit `conditions` when no enabled feature requires a host-bound condition. Conditions
-computed through `source`/`select` bind automatically; external conditions still require their sources (D271).
-
-The synchronous constructor exposes `ready`, so a test can inspect a pending lazy body before readiness.
-`waitFor(snapshot => predicate, { label, timeoutMs, pollIntervalMs })` wakes on inspection changes and also polls
-external UI predicates; `notify()` wakes it after a controlled fixture update. The default deadline is 1000ms,
-with a 10ms predicate poll. A `ScenarioTimeoutError` carries the data-only snapshot, bounded history and observed
-conditions, feature phases, body loads, lane blockers and resource lease facts. It does not infer repository
-or network causes. `getSnapshot()` and `history()` use that same observation model; history defaults to 64 snapshots,
-activity to 256 records. Capacities accept integers from 1 to 10000. Do not replace predicates with a fixed number of ticks.
-
-`close()` fences application admission synchronously, unmounts all registered screens and joins their cleanup with
-physical application drain. Its deadline does not cancel cleanup: a later `close()` can await the same drain.
-A readiness deadline likewise leaves the application available for inspection and explicit cleanup.
-`ownership()` reports only registered runtime ownership, with `unknown` for missing, stale or truncated evidence;
-a workspace stale snapshot is complete only after the scenario witnessed successful physical cleanup. This permits
-a scoped zero-count assertion, without proving absence of arbitrary host, UI or GC leaks. Successful cleanup clears
-application imports and internal renderer references. A failed cleanup promise can retain original errors and retry
-capabilities; a caller that keeps `mounted.host` also keeps its own renderer result.
-
-The inspection schemas are `opetope.devtools-graph/5` and `opetope.devtools-frame/5`, with optional
-`opetope.runtime-activity/4` snapshots (D266, D275, D344, D358). Within one session,
-a frame without `activity` preserves the previous activity; a full snapshot/reset without it clears that observation
-(D216). Activity-bearing frames replace the previous activity in full.
-Use matching runtime/devtools versions: previous graph/frame and activity revisions are rejected; weak-edge presence requires graph `/5` and frame `/4`. Activity identifies the execution,
-actual feature generation, physical calls, exact current lane blockers, and for every registered Resource its
-`kind`, `lifetime`, `epoch`, `state`, `activity` with its `operation`, `leases`, `subscribers`, `pagination` and the
-`epoch` of each physical load — there is no `attempt` and no numeric generation, because a Resource runs one logical
-attempt and recovery belongs to the transport (D358). Host demand and UI models are unknown. `freshness`
-and `truncated` distinguish a complete live view from a partial or detached one. A closed session is stale;
-`closed: true` says that the close of the application finished, whether its physical drain succeeded or refused, and
-the snapshot of a closed application names no feature and no Resource (D427). No control authority or product payload is added.
-Activity output is bounded by record capacity. Snapshot collection still visits registered owners, executors and
-resources, so capacity does not bound traversal cost. Collection stops once truncation is proven;
-idle executors may still require traversal to establish completeness. Normal call dispatch allocates no diagnostic record with
-observation disabled. Graph frames remain bounded by the existing ring capacity.
-
-## Testing
-
-`@opetope/react/testing` exports component fixtures and application scenarios, and re-exports
-`@opetope/runtime/testing` — which in turn re-exports `@opetope/core/testing` — so a React test names one entry
-(D285):
-
-- `renderSlot(target, { contribution, models, props })` mounts the published target or one fixture contribution;
-- `command(run)` produces an authentic `Command` for a model fixture, plus the contribution binding a mount reads;
-- `runCommand(target, input?, options?)` executes an existing authentic `Command` without mounting React (D261);
-- `testReadable(initial)`, `testResourceEpoch()`, `openModel`, `settled`, `waitFor`, `yieldTurn` and `eventually`
-  come from the entries below, for the part of a test that has no UI in it — `testResourceEpoch()` is what a
-  component fixture writing a `ResourceState` by hand puts in its `epoch` (D362).
-
-A test that renders nothing should import `@opetope/runtime/testing` directly: `renderSlot` and the binding half of
-`command` are all that needs React here. The Command a fixture mints is the `command` of `@opetope/core/testing`
-(D300), and this word is the one name of the re-export chain that does not pass through: the React `command`
-shadows it with the stronger one.
-
-The `renderSlot` harness returns `Slot` and `updateProps`: there are no roots and no fixtures for them, UI enters the
-application as contributions (D85). It is not a test spelling of `<Slot>` — it mounts a fixture and takes a
-`reporter`, because a component test has no feature to report to — and the packaged consumer of `ci:pack` mounts it
-from the real archive (D301).
-
-A test that previously mounted `useCommand` only to invoke a Command can use `runCommand` directly. The result is the
-Command's output, while a UI test still checks the `CommandOutcome` returned by the mounted consumer:
-
-```ts
-import assert from 'node:assert/strict';
-import { defineModel } from '@opetope/core';
-import type { Command, ModelCommandContext } from '@opetope/core';
-import { defineFeature, openFeature } from '@opetope/runtime';
-import { runCommand } from '@opetope/react/testing';
-
-const Arithmetic = defineModel<{ readonly double: Command<number, number> }>('example.testing.model');
-const arithmetic = defineFeature('example.testing.arithmetic', {
-  own: ({ model }) => ({
-    arithmetic: model(Arithmetic, context => ({
-      double: context.command(({ input }: ModelCommandContext<number>) => input * 2),
-    })),
-  }),
-  exports: ({ own }) => ({ double: own.arithmetic.double }),
-});
-const instance = openFeature(arithmetic, { imports: {}, reporter: () => undefined });
-try {
-  const ready = await instance.ready;
-  const result = await runCommand(ready.exports.double, 3);
-  assert.equal(result, 6);
-} finally {
-  await instance.close();
-}
-```
+For a contributor checkout, use `npm run ci:type --workspace @opetope/react` and
+`npm run ci:test --workspace @opetope/react` where provided. The root `npm run check` performs full acceptance;
+[contributor commands](../runtime/docs/maintainers/contributing.md) describe the build and package checks.
 
-`runCommand` returns `Promise<Output>` and preserves the Command's original errors and cancellation rejections. It adds no
-UI status or outcome wrapper, scheduling policy, model creation or cleanup lifetime. The existing Command retains its
-owner, lane and retirement rules; the test closes the instance it opened, including after failed readiness.
-A void Command can use `runCommand(target)`. Options always occupy the third argument:
-`runCommand(target, input, { signal })`, or `runCommand(voidTarget, undefined, { signal })`.
-`RunCommandOptions` contains only the optional `signal`; a pre-aborted signal rejects before the body runs.
+<a id="hello-ui"></a>
+[See Hello UI](../runtime/docs/reference/react.md#react-hello-ui).
 
-`run`, `runCommand` and nested `invoke` use the same no-input rule (D273): `void` and `undefined` allow omission;
-other inputs, including `T | undefined`, require an argument. `never` cannot be invoked without input.
-Generic helpers may forward the target and its explicit input without losing their types.
+<a id="selecting-data-and-commands"></a>
+[See Selecting data and commands](../runtime/docs/reference/react.md).
 
-## Word map and entries
+<a id="application-host"></a>
+[See Application host](../runtime/docs/reference/react.md).
 
-| Entry                        | What it holds                                                                                                                                                                                                                                                                                                                        |
-| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `@opetope/react`             | `useModel`, `useCommand`, `useReadable`, `useSelector`, `useResource`, `requiresModels`, `defineSlot`, `defineSwitchSlot`, `Slot`, `ContributionError`; types `SlotTarget`, `SwitchSlotTarget`, `SlotContribution`, `CommandHook`, `CommandOutcome`, `ResourceHook`, `PaginatedResourceHook`, `ResourcePaginationHook`               |
-| `@opetope/react/integration` | `FeatureBoundary`, `ContributionBoundary`, `useFeature`, `useFeatureRetry`, `FeatureBoundaryError` for the integration layer; types `FeatureBoundaryProps`, `ContributionBoundaryProps`, `ContributionErrorContent`, `ContributionFailure`, `FeatureDemandSource`, `FeatureDemandState`, `FeatureDemandResult`, `FeatureDemandLease` |
-| `@opetope/react/testing`     | `renderSlot`, `command`, `createScenario`, `ScenarioTimeoutError` and fixture/scenario types, plus everything `@opetope/runtime/testing` and `@opetope/core/testing` publish; tests only                                                                                                                                             |
+<a id="feature-demand-boundary"></a>
+[See Feature demand boundary](../runtime/docs/reference/react.md).
 
-`Command<Input, Output>` is imported from `@opetope/core`; UI `CommandOutcome<Output>` is imported from `@opetope/react`. The former `Command` synonym and the `CommandOutcome` re-export from `@opetope/react/integration` are removed (D270).
+<a id="contributions"></a>
+[See Contributions](../runtime/docs/reference/react.md).
 
-`Model` is a typed key for a record of `Readable`, `Command` and readable factories that UI components consume.
-The constructors of the integration entry are not re-exported from the safe entry and cannot come back into
-`ui/models/data/contracts` through a local barrel of a feature.
+<a id="scenario-tests-and-physical-activity"></a>
+[See Scenario tests and physical activity](../runtime/docs/reference/react.md).
 
-## Laws
+<a id="testing"></a>
+[See Testing](../runtime/docs/reference/react.md).
 
-- `useModel(declaration)` reads only the models declared by the contribution;
-- one committed contribution owns its model frame until unmount or retire;
-- an abandoned concurrent render holds no frame;
-- `useCommand` does not subscribe to the invoker: the observable state of a call lies in a `Readable` of the model;
-- the `cancelled` outcome does not move `outcome`, and it is only the `CommandError` codes `cancelled`
-  and `closed`; a call to a weak port with no provider (`unavailable`) and a rejected publication
-  (`publication-rejected`) arrive as the `failed` outcome and settle in `outcome` (D138, D292);
-- a contribution that fails to render or to commit is contained by its own mount and reported to its feature;
-- `useSelector` reads its `equals` where the selected value is known, so a named non-generic comparator compiles
-  beside a selection whose parameter is inferred, as it does in Core (D348);
-- `useSelector` keeps the selected reference when something else changed; its identity case is `useReadable` and its
-  model case is a `useModel` selection, so it is proven by the memory gate and the packaged consumer rather than by a
-  specification example, and it is a candidate to leave this entry until a second application is measured (D301);
-- closing and unmounting synchronously fence new calls and release the references of the frame.
+<a id="word-map-and-entries"></a>
+[See Word map and entries](../runtime/docs/reference/react.md).
 
-## Compatibility contract
+<a id="laws"></a>
+[See Laws](../runtime/docs/reference/react.md).
 
-The ESM of the package is built for Chrome 82+, Firefox 110+, Safari/iOS 15+, Android 82+ and Node 20.19+ and requires
-the peer `react >=19.0.0 <20` (D251). React and ReactDOM are peers of the host, not built-in polyfills. The raw modules are
-executed by an HTTP import smoke test with a local bundle of the peers; historical browser builds are checked only by an external farm.
+<a id="compatibility-contract"></a>
+[See Compatibility contract](../runtime/docs/reference/react.md).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@opetope/react",
-  "version": "0.12.0",
+  "version": "0.12.1",
   "engines": {
     "node": ">=20.19.0"
   },
@@ -15,7 +15,6 @@
   "files": [
     "dist",
     "README.md",
-    "README.ru.md",
     "LICENSE",
     "CHANGELOG.md"
   ],
@@ -50,16 +49,16 @@
     }
   ],
   "devDependencies": {
-    "@opetope/core": "0.12.0",
-    "@opetope/runtime": "0.12.0",
+    "@opetope/core": "0.12.1",
+    "@opetope/runtime": "0.12.1",
     "@testing-library/react": "16.3.3",
     "@types/react": "19.2.18",
     "react": "19.2.8",
     "react-dom": "19.2.8"
   },
   "peerDependencies": {
-    "@opetope/core": "0.12.0",
-    "@opetope/runtime": "0.12.0",
+    "@opetope/core": "0.12.1",
+    "@opetope/runtime": "0.12.1",
     "react": ">=19.0.0 <20"
   },
   "sideEffects": false,

package/README.ru.md

@@ -1,401 +0,0 @@
-# `@opetope/react`
-
-React-привязка для моделей и UI-вкладов Opetope. Словарь пакета задаёт §3 [спецификации](../runtime/docs/spec.ru.md).
-
-## Установка
-
-```sh
-npm install @opetope/core @opetope/runtime @opetope/react 'react@^19.0.0' 'react-dom@^19.0.0'
-```
-
-Используйте согласованные версии Opetope. Для release candidate добавьте `@next` каждому пакету `@opetope/*` в команде.
-API поставляется только в ESM; требуется Node 20.19+. Команды разработки ниже относятся к contributor checkout.
-
-Нормативные руководства EN/RU поставляются в `@opetope/runtime`: после его установки откройте
-`node_modules/@opetope/runtime/docs/spec.md` или `spec.ru.md`; рецепты находятся в `cookbook.md` и `cookbook.ru.md`.
-Для чтения установленных руководств доступ к GitHub не нужен.
-
-## Hello UI
-
-```tsx
-import { defineModel } from '@opetope/core';
-import type { Command, Readable } from '@opetope/core';
-import { defineSlot, requiresModels, Slot, useModel } from '@opetope/react';
-
-const CounterModel = defineModel<{
-  readonly count: Readable<number>;
-  readonly increment: Command<void, void>;
-}>('example.counter.model');
-const CounterSlot = defineSlot<{ readonly label: string }>('example.counter.slot');
-
-const CounterButton = requiresModels([CounterModel])(({ label }: { readonly label: string }) => {
-  const {
-    count,
-    increment: { run, inFlight, outcome },
-  } = useModel(CounterModel, (model, { read }) => ({
-    count: read(model.count),
-    increment: model.increment,
-  }));
-
-  return (
-    <button disabled={inFlight} onClick={() => void run()}>
-      {outcome?.kind === 'failed' ? 'Retry' : `${label}: ${count}`}
-    </button>
-  );
-});
-
-function CounterArea() {
-  return <Slot props={{ label: 'Count' }} target={CounterSlot} />;
-}
-```
-
-Компонент не получает ни сервис, ни класс, ни ref рантайма. Монтирование вклада неявно выдаёт модели `own` его фичи;
-компонент или хук, читающий per-mount модель, объявляет её через `requiresModels`. `useModel` читает ровно этот кадр
-авторитета. `useCommand` отдаёт `{ run, inFlight, outcome }`
-и всегда resolve-ит исход, поэтому штатная отмена не становится unhandled rejection (D116, D292).
-
-`outcome` — последний завершившийся не-отменённый исход этого потребителя: `ok` встаёт на место прежнего `failed`,
-`failed` — на место прежнего `ok`, исход `cancelled` не двигает ничего, и старт прогона ничего не чистит, поэтому
-отказ читается, пока идёт повтор. До первого завершения он `undefined`. Читают его по дискриминанту —
-`outcome?.kind === 'failed' ? outcome.error : null`.
-
-Команда без входа привязывается к событию стрелкой: `onClick={() => void logout.run()}`. Именно стрелка не пускает
-React-событие в Command и не оставляет промис висеть; `onClick={logout.run}` не компилируется, потому что `MouseEvent`
-не ложится в `void`. Для данных, исхода, callbacks или сигнала отдельного вызова используйте `run(input, options?)`.
-Там, где конфиг линтера запрещает стрелку прямо в пропсе (`react-perf/jsx-no-new-function-as-prop`,
-`react/jsx-no-bind`), её поднимают через `useCallback(() => void logout.run(), [logout.run])`: зависимость — `run`,
-а не объект хука (D290).
-
-`run` стабилен, пока invoker тот же; возвращённый объект — снимок того рендера, в котором его прочитали, и меняется
-вместе с `inFlight` или `outcome`, поэтому эффект или memo зависят от `run`, а не от хука, — правило
-`opetope/no-command-in-deps` держит это за автора (D290). Сохранённый `run` заменённого или
-размонтированного потребителя закрыт для новых вызовов и не перенаправляет работу на замену.
-
-Хук ничего не планирует. Каждый `run` доходит до команды, и решает порядок, с которым команда объявлена (D203).
-Для setter абсолютного значения модель объявляет `concurrency: 'latest'` в `context.command`, и новый вход
-заменяет ожидающий именно там (D185, D387). За потребителем остаётся своё: уже отменённый входной signal
-отвергается как `cancelled`, не доходя до команды, `run` размонтированного потребителя отвергается так же,
-`inFlight` истинен, пока не завершился хоть один начатый им прогон, и у каждого прогона свои callbacks и signal.
-
-Чтобы объединить эквивалентную ожидающую или исполняющуюся работу, модель объявляет `dedupe: true` либо
-`dedupe: input => key` у `context.command`. Сохраняются первый вход и независимая отмена каждого вызывающего;
-обе формы запрещены с `latest` (D277). Это опции Command, а не хука.
-
-Для нескольких команд компонент пишет `useCommand` на команду либо одну выборку `useModel`, которая и так
-отдаёт готовые хуки. `useCommands` удалён: запись поверх единственного `CommandHook` была сахаром, экономившим
-вызовы хуков, а не вторым механизмом, и нужный набор — это выбор в модели, где у него есть владелец и время
-жизни, которые даёт `ctx.select` (D388).
-
-Два псевдонима одного Command имеют независимые локальные статусы, как два потребителя `useCommand`; они
-используют один порядок Command и одну command-запись монтирования (D197, D203). Выборка не вводит общий busy,
-очередь или транзакцию; контролам, перезаписывающим одно значение, по-прежнему нужна одна смысловая команда.
-
-## Выбор данных и команд
-
-`useModel(Declaration, (model, { read }) => ({ ... }))` объединяет явный выбор данных и command consumers (D205, D214).
-
-Результат выбора модели может быть именованным interface без index signature (D217). Результат — плоская запись данных;
-arrays, functions, constructors и встроенные объекты коллекций, дат и promises не являются selection records.
-`read(source)` возвращает снимок; `read(source, project)` — проекцию. Authentic Commands, выбранные полями record,
-превращаются в тот же `CommandHook`, что у `useCommand`, с независимыми статусами aliases и стабильным `.run`.
-Одну команду можно выбрать без вложенных hooks:
-
-```tsx
-const { logout } = useModel(AuthModel, auth => ({ logout: auth.logout }));
-return (
-  <button disabled={logout.inFlight} onClick={() => void logout.run()}>
-    Log out
-  </button>
-);
-```
-
-Форма с одним аргументом по-прежнему возвращает выданную модель; отдельные hooks сохраняются.
-
-Подписка создаётся только на явно прочитанные источники, одна на каждый различный Readable внутри selection.
-Поля данных сравниваются через `Object.is`: выбирайте скаляры, раскрывайте проекцию record в selection или
-возвращайте стабильные ссылки. Новый вложенный объект считается изменившимся полем. Callback чистый:
-без hooks, команд и side effects. Ошибка read/selector попадает в ближайший React error boundary.
-Изменение источников и ключей команд применяется в commit; abandoned render не меняет действующие полномочия.
-
-Hook не создаёт модель и не приобретает feature. Он арендует ровно те ресурсы, которые выборка назвала
-значениями: такое поле отвечает `ResourceHook`, и одна аренда на identity Resource покрывает всё монтирование, даже
-когда один Resource назвали два ключа (D321, D359). Больше ничего:
-`read(resource.state)` не арендует, и однопараметрическая форма тоже. Объединение hooks не обещает меньше подписок или
-более быстрый render; импорт обычного `useModel` теперь также включает реализацию selection. Дополнительного
-scheduler для Command нет.
-
-## Application host
-
-Хост открывает граф фич через `openApplication`. Готовые фичи атомарно публикуют UI-вклады;
-обычный `Slot` монтирует их в consumer-owned целях:
-
-```tsx
-<Slot target={exampleFooterSlot} />
-<Slot target={exampleSettingsSlot} />
-```
-
-Приложение владеет временем жизни фич; UI каждой фичи монтируется через её вклады.
-
-## Граница спроса на фичу
-
-```tsx
-import { Slot } from '@opetope/react';
-import { FeatureBoundary, useFeatureRetry } from '@opetope/react/integration';
-
-function Retry() {
-  return <button onClick={useFeatureRetry()}>Try again</button>;
-}
-
-<FeatureBoundary demand={host} error={<Retry />} fallback={<Spinner />}>
-  <Slot props={{ itemId, onConfirmed }} target={confirmActionContentSlot} />
-</FeatureBoundary>;
-
-// или с render-колбэками, когда нужен сам готовый экземпляр (D177)
-<FeatureBoundary
-  demand={host}
-  error={({ error, retry }) => <Failure error={error} onRetry={retry} />}
-  fallback={<Spinner />}
->
-  {({ exports }) => <TasksResourceLease resource={exports.tasks}>{children}</TasksResourceLease>}
-</FeatureBoundary>;
-```
-
-`FeatureBoundary` принимает `FeatureDemandSource` от интеграции с хостом. Он держит спрос на фичу,
-показывает готовую ветвь после готовности спроса и изолирует `useFeatureRetry` в поддереве ошибки. Ветвь может быть узлом или
-render-колбэком: колбэк `children` получает готовый экземпляр, типизированный по `demand`, колбэк `error` получает
-`{ error, retry }`, и выполняется только показанная ветвь. Своего `useFeature` колбэку не нужно, поэтому готовый
-потребитель не берёт спрос второй раз; хуки по-прежнему живут в дочерних компонентах, а не в колбэке. Отдельного хука для чтения ошибки
-нет: хост сам передал её в `error`, поэтому знает её без второго слова (D142). UI входит в фичу через `Slot`: ни
-корня, ни секции `ui`, ни второго API привязки больше нет (D85).
-
-И boundary, и голый `useFeature` проверяет упакованный потребитель `ci:pack` — на общем для них законе: одна аренда
-на монтирование, сохраняется через севший `retry` и отпускается на размонтировании. `useFeature` это хуковая
-половина для случая, когда готовность рендерит сам хост, и он кандидат на вывод с этого входа до второго
-измеренного приложения; `FeatureBoundary` не пара `ContributionBoundary` и остаётся (D301).
-
-## Contributions
-
-```tsx
-import { defineSlot, defineSwitchSlot, Slot } from '@opetope/react';
-
-const HeaderEnd = defineSlot<{ readonly mode: 'desktop' | 'phone' }>('example.headerEnd');
-const PageEnd = defineSwitchSlot<'home' | 'wallet', { readonly compact: boolean }>('example.pageEnd');
-
-function Header({ mode }: { readonly mode: 'desktop' | 'phone' }) {
-  return <Slot props={{ mode }} target={HeaderEnd} />;
-}
-
-function HomePageEnd() {
-  return <Slot props={{ compact: true }} target={PageEnd('home')} />;
-}
-```
-
-`defineSlot` создаёт подлинную цель с упорядоченным множеством вкладов; `defineSwitchSlot` лениво создаёт и
-кеширует стабильную цель на каждый маршрут. `Slot` читает атомарный снимок и рендерит каждый `{ Component }` в кадре
-авторитета того экземпляра, который вклад дал. Порядок и стабильный ключ приходят из записей вкладов ядра, поэтому
-React не вводит второй компаратор и второй реестр времени жизни. Упакованный потребитель `ci:pack` проверяет это
-кеширование и проводит через него один вклад (D301).
-
-`useResource(resource)` отвечает `{ pagination, refresh, reset, retry, state }`: `ResourceState` через
-`useSyncExternalStore`, арендой, которую отдаёт `resource.acquire()`, взятой в commit-эффекте на всё время
-монтирования компонента, и тремя глаголами как обычными потребителями `CommandHook` (D359). Поэтому прерванный
-render не открывает ничего, а при смене ссылки состояние следует новому Resource, и cleanup эффекта освобождает
-предыдущую аренду. Число React-хуков от Resource не зависит: объявление без `pagination` подписывается на
-постоянный источник и держит `loadNext`, который отвечает `skipped`, а объявление, несшее эту capability, отвечает
-`pagination` записью `{ loadNext, state }` (D356). Поле выборки `useModel`, значением которого является Resource,
-отвечает тем же хуком и берёт ту же аренду, поэтому модель не объявляет `Command<void, void>` вокруг
-`resource.refresh()` ради `inFlight` в кнопке. `useReadable(resource)` — это ошибка компиляции, потому что Resource
-не `Readable`; `useReadable(resource.state)` и `read(resource.state)` в селекторе остаются пассивными и не арендуют
-ничего: наблюдать и держать — независимые вопросы, поэтому селектор, читающий состояние, и стоящий рядом
-`useResource` подписываются дважды (D349). Обе стороны показывает компилируемый пример спецификации §2.13
-(D301, D321).
-
-`refresh.run()`, `retry.run()` и `reset.run()` доходят до Resource, которым владеет объявившая его модель:
-`inFlight` истинен, пока не осел исход операции, `outcome` несёт этот `ResourceOperationOutcome` значением `value`
-при статусе `ok`, а `run(undefined, { signal })` отменяет ожидание этого потребителя, а не работу, которой владеет
-модель. Два потребителя одного Resource держат раздельные статусы, а `run` сохраняет ссылку, пока та же
-идентичность Resource. Render, догнавший retirement, рисует терминальную запись — `idle` с причиной `retired` у Resource, которым
-владеет модель, и `unleased` у фасада фичи, потому что эта ссылка переживает экземпляр, — и размонтируется, отпустив
-аренду (D359, D364). Ничто здесь не отказывает в чтении из-за того, что кончилась чья-то жизнь: источник, у которого
-ушёл владелец, останавливается и продолжает отвечать последним значением, поэтому `useReadable`, `useSelector` с
-inline-селектором и `read` выборки просто читают дальше, и собственная память им не нужна. Оставшийся отказ — это
-упавшая работа: упавшее состояние, сломанный курсор пагинации, — и он по-прежнему доходит до рендера.
-
-Прямые пропсы компонента, `props`-адаптер вклада и props-`Readable` его модели используют один снимок
-монтирования. Входящие пропсы слота публикуются в layout до paint, поэтому прямой и адаптированный рендеры
-не смешивают новые пропсы со старым снимком модели. Отказ фабрики модели убирает частично созданный kernel.
-Модели принадлежат коммиту: брошенный рендер не создаёт модель, которую пришлось бы убирать (D170, D188).
-Повтор эффектов StrictMode и скрытие/раскрытие Suspense сохраняют закоммиченный набор моделей и состояние.
-Только реальная замена идентичности или размонтирование освобождает его; при скрытом размонтировании это делает
-микрозадача после того, как React отключил layout-эффекты (D209).
-
-Retry спроса привязан к источнику. После замены источника boundary новый retry может начаться, даже если retry
-старого ещё не завершён.
-
-Каждое монтирование — граница ошибок своего вклада (D256). Сбой рендера или коммита останавливается на нём, уходит в
-reporter опубликовавшей вклад фичи и не трогает остальные монтирования цели. `ContributionBoundary` один раз, над
-всеми слотами, говорит, что показывает упавшее монтирование:
-
-```tsx
-import { ContributionBoundary } from '@opetope/react/integration';
-
-<ContributionBoundary error={({ error, retry }) => <FailedContribution error={error} onRetry={retry} />}>
-  <Slot target={applicationSurface} />
-</ContributionBoundary>;
-```
-
-`error` принимает узел или колбэк `{ contribution, error, feature, retry, target }` — форму отказа `FeatureBoundary`
-плюс идентичность упавшего: `contribution` — опубликованная запись `<фича>.<ключ provides>`, `target` — слот, поэтому
-одна ветвь может отвечать по поверхности. `retry` перемонтирует вклад, поэтому его модели создаются заново. Reporter
-опубликовавшей фичи получает ту же идентичность на `ContributionError`, у которого в `cause` исходная ошибка, с кодом
-`render-failed` или `error-content-failed`. Без провайдера упавшее монтирование рендерит пустоту:
-изоляция от него не зависит. Упавшее содержимое ошибки изолируется так же и сообщается, а не эскалируется.
-
-## Сценарные тесты и физическая активность
-
-`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 команд.
-
-Как и в `openApplication`, `conditions` можно опустить, если включённые фичи не требуют условий от хоста.
-Условия с `source`/`select` связываются автоматически; внешним условиям по-прежнему нужны источники (D271).
-
-Синхронный конструктор возвращает `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 использует схемы `opetope.devtools-graph/5` и `opetope.devtools-frame/5`, а также optional snapshots
-`opetope.runtime-activity/4` (D266, D275, D344, D358). В пределах одной session
-frame без `activity` сохраняет предыдущую activity; полный snapshot/reset без этого поля очищает наблюдение (D216).
-Frame с `activity` заменяет предыдущую activity целиком.
-Используйте согласованные версии runtime/devtools: предыдущие ревизии графа, кадров и activity отвергаются; presence слабого ребра требует graph `/5` и frame `/4`. Activity указывает execution,
-фактическое поколение feature, физические вызовы, точных текущих lane blockers, а для каждого зарегистрированного
-Resource — его `kind`, `lifetime`, `epoch`, `state`, `activity` вместе с `operation`, `leases`, `subscribers`,
-`pagination` и `epoch` каждой физической загрузки: ни `attempt`, ни числового generation здесь нет, потому что
-Resource делает одну логическую попытку, а восстановление принадлежит транспорту (D358). Спрос хоста и UI-модели
-неизвестны. `freshness`
-и `truncated` отличают полное live-наблюдение от усечённого или отключённого. Закрытая session имеет stale-снимок;
-`closed: true` говорит, что закрытие приложения завершилось, успешным был его физический drain или отказавшим, и
-снимок закрытого приложения не называет ни одной фичи и ни одного Resource (D427). Control authority и продуктовые payload не добавляются.
-Размер activity ограничен capacity записей. Сбор снимка обходит зарегистрированных owners, executors и resources,
-поэтому capacity не ограничивает стоимость обхода. Сбор останавливается после доказанного truncation;
-idle executors могут требовать обхода, чтобы подтвердить полноту данных. Обычный call dispatch не создаёт диагностических записей при
-выключенном наблюдении. Frames ограничены существующей ring capacity.
-
-## Testing
-
-`@opetope/react/testing` экспортирует fixtures компонентов и сценарии приложения, а также реэкспортирует
-`@opetope/runtime/testing`, который, в свою очередь, реэкспортирует `@opetope/core/testing`, поэтому React-тест
-называет один вход (D285):
-
-- `renderSlot(target, { contribution, models, props })` монтирует опубликованную цель либо один вклад-фикстуру;
-- `command(run)` выдаёт подлинный `Command` для фикстуры модели плюс привязку вклада, которую читает монтирование;
-- `runCommand(target, input?, options?)` запускает существующий подлинный `Command` без монтирования React (D261);
-- `testReadable(initial)`, `testResourceEpoch()`, `openModel`, `settled`, `waitFor`, `yieldTurn` и `eventually`
-  приходят из входов ниже — для той части теста, в которой UI нет; `testResourceEpoch()` это то, что фикстура
-  компонента, собирающая `ResourceState` руками, кладёт в её `epoch` (D362).
-
-Тест, который ничего не рендерит, должен импортировать `@opetope/runtime/testing` напрямую: React здесь нужен
-только `renderSlot` и привязочной половине `command`. Сам Command фикстуры чеканит `command` из
-`@opetope/core/testing` (D300), и это единственное имя цепочки реэкспортов, которое насквозь не проходит:
-React-`command` заслоняет его своим, более сильным.
-
-Харнесс `renderSlot` отдаёт `Slot` и `updateProps`: корней и их фикстур больше нет, UI входит в приложение
-вкладами (D85). Это не тестовое написание `<Slot>`: он монтирует фикстуру и принимает `reporter`, потому что у
-компонентного теста нет фичи, которой можно сообщить, — и упакованный потребитель `ci:pack` монтирует его из
-настоящего архива (D301).
-
-Тест, который раньше монтировал `useCommand` только ради вызова Command, может использовать `runCommand` напрямую.
-Результат — выход Command; тест UI по-прежнему проверяет `CommandOutcome`, возвращённый смонтированным consumer:
-
-```ts
-import assert from 'node:assert/strict';
-import { defineModel } from '@opetope/core';
-import type { Command, ModelCommandContext } from '@opetope/core';
-import { defineFeature, openFeature } from '@opetope/runtime';
-import { runCommand } from '@opetope/react/testing';
-
-const Arithmetic = defineModel<{ readonly double: Command<number, number> }>('example.testing.model');
-const arithmetic = defineFeature('example.testing.arithmetic', {
-  own: ({ model }) => ({
-    arithmetic: model(Arithmetic, context => ({
-      double: context.command(({ input }: ModelCommandContext<number>) => input * 2),
-    })),
-  }),
-  exports: ({ own }) => ({ double: own.arithmetic.double }),
-});
-const instance = openFeature(arithmetic, { imports: {}, reporter: () => undefined });
-try {
-  const ready = await instance.ready;
-  const result = await runCommand(ready.exports.double, 3);
-  assert.equal(result, 6);
-} finally {
-  await instance.close();
-}
-```
-
-`runCommand` возвращает `Promise<Output>` и сохраняет исходные ошибки и причины отклонения при отмене Command. Он не добавляет
-UI-статус, обёртку outcome, политику выполнения, создание модели или отдельное время жизни для cleanup. У Command остаются
-его владелец, lane и правила retirement; тест закрывает открытый экземпляр, в том числе при отказе readiness.
-Для void Command достаточно `runCommand(target)`. Options всегда передаются третьим аргументом:
-`runCommand(target, input, { signal })` или `runCommand(voidTarget, undefined, { signal })`.
-`RunCommandOptions` содержит только необязательный `signal`; уже отменённый сигнал отклоняет вызов до входа в его тело.
-
-`run`, `runCommand` и вложенный `invoke` используют одно правило входа (D273): `void` и `undefined` можно опустить;
-остальные входы, включая `T | undefined`, требуют аргумент. `never` нельзя вызвать без входа.
-Обобщённые функции могут передавать цель и её явный вход с сохранением типов.
-
-## Карта слов и входы
-
-| Вход                         | Что содержит                                                                                                                                                                                                                                                                                                                   |
-| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `@opetope/react`             | `useModel`, `useCommand`, `useReadable`, `useSelector`, `useResource`, `requiresModels`, `defineSlot`, `defineSwitchSlot`, `Slot`, `ContributionError`; типы `SlotTarget`, `SwitchSlotTarget`, `SlotContribution`, `CommandHook`, `CommandOutcome`, `ResourceHook`, `PaginatedResourceHook`, `ResourcePaginationHook`          |
-| `@opetope/react/integration` | `FeatureBoundary`, `ContributionBoundary`, `useFeature`, `useFeatureRetry`, `FeatureBoundaryError` для integration-слоя; типы `FeatureBoundaryProps`, `ContributionBoundaryProps`, `ContributionErrorContent`, `ContributionFailure`, `FeatureDemandSource`, `FeatureDemandState`, `FeatureDemandResult`, `FeatureDemandLease` |
-| `@opetope/react/testing`     | `renderSlot`, `command`, `createScenario`, `ScenarioTimeoutError` и типы fixtures/scenarios плюс всё, что публикуют `@opetope/runtime/testing` и `@opetope/core/testing`; только для тестов                                                                                                                                    |
-
-`Command<Input, Output>` импортируется из `@opetope/core`, а UI-результат `CommandOutcome<Output>` — из `@opetope/react`. Прежний синоним `Command` и переэкспорт `CommandOutcome` из `@opetope/react/integration` удалены (D270).
-
-`Model` — типизированный ключ записи из `Readable`, `Command` и фабрик readable, которую используют UI-компоненты.
-Конструкторы integration-входа не переэкспортируются из безопасного входа и не могут вернуться в
-`ui/models/data/contracts` через локальный barrel фичи.
-
-## Законы
-
-- `useModel(declaration)` читает только модели, объявленные вкладом;
-- один закоммиченный вклад владеет своим кадром моделей до размонтирования или retire;
-- брошенный concurrent-рендер кадр не удерживает;
-- `useCommand` не подписывается на invoker: наблюдаемое состояние вызова лежит в `Readable` модели;
-- исход `cancelled` не двигает `outcome`, и это только коды `CommandError` `cancelled`
-  и `closed`; вызов слабого порта без провайдера (`unavailable`) и отклонённая публикация
-  (`publication-rejected`) приходят исходом `failed` и оседают в `outcome` (D138, D292);
-- вклад, упавший в рендере или коммите, изолируется своим монтированием и сообщается своей фиче;
-- `useSelector` читает свой `equals` там, где выбранное значение уже известно, поэтому именованная необобщённая
-  функция компилируется рядом с выборкой, параметр которой выводится, — как в Core (D348);
-- `useSelector` сохраняет выбранную ссылку, когда изменилось что-то другое; его тождественный случай это
-  `useReadable`, а случай поля модели — выборка `useModel`, поэтому доказывают его гейт памяти и упакованный
-  потребитель, а не пример спецификации, и он кандидат на вывод с этого входа до второго измеренного
-  приложения (D301);
-- закрытие и размонтирование синхронно фенсят новые вызовы и освобождают ссылки кадра.
-
-## Compatibility contract
-
-ESM пакета собирается для Chrome 82+, Firefox 110+, Safari/iOS 15+, Android 82+ и Node 20.19+ и требует peer
-`react >=19.0.0 <20` (D251). React и ReactDOM это peers хоста, а не встроенные полифилы. Сырые модули исполняет smoke импорта
-по HTTP с локальным бандлом peer-ов; исторические сборки браузеров проверяет только внешняя ферма.