@opetope/runtime 0.1.0

package/docs/spec.md

@@ -0,0 +1,874 @@
+# Opetope — Framework Specification
+
+Normative specification of the Opetope feature-composition framework: `@opetope/core`, `@opetope/runtime`,
+`@opetope/react`. Everything below describes the framework as it is. Where a rule would otherwise look arbitrary, a
+single trailing pointer names the decision that fixed it.
+
+---
+
+## 1. Purpose and principles
+
+Opetope composes features: a graph of features with explicit dependencies, owned state with an exact lifecycle,
+typed calls with policies, extension points with cardinality, and a React layer without a service locator. Slots
+and the explicit graph form a small author vocabulary. The runtime owns lifecycle, subscriptions and call guards;
+observed data follows the lifetime of its readers without hand-written `useEffect`.
+
+An explicit non-goal: SSR, hydration and persistence. Data lives in the models and resources of an instance and is not
+serialized — the framework offers neither a snapshot for a server nor a restore from one; moving that boundary is a
+separate RFC (see decisions.md, D155).
+
+Everything else is derived from these principles.
+
+1. **One semantic fact is declared once.** Mechanical consequences are produced by normalization and checked by
+   validation.
+2. **One concept, one word, at every stage.** A model is declared with `defineModel`, created with `model(...)`, read
+   with `useModel`.
+3. **A feature author sees only the author vocabulary.** The kernel, the instance machine, the IR and authority live
+   in `internal` for framework implementation and host integration. The cap is 40 value exports and 60 types
+   across the three safe entries.
+4. **Only `id` is mandatory.** Sections appear on demand; an author never writes an empty section.
+5. **Layers are separated physically.** A feature's UI imports only that feature's own contracts. A model knows
+   nothing about the feature, its ports or its imports: it declares its dependencies as its own interface and the
+   feature supplies them. Another feature is reachable only through `imports` or `requires`.
+6. **Sugar lowers into one IR.** Every short form has a compile test proving equivalence to the long form and creates
+   no second runtime path.
+7. **The framework is independent of its host.** Application adapters depend on `@opetope/*`; framework packages
+   do not depend on application code. Host services enter through explicit contracts.
+
+---
+
+## 2. The shape of a feature
+
+A feature is one `defineFeature` with seven sections. The example uses two features: `catalog.catalog` owns the item
+catalog and offers a "resolve item" port; `checkout.createForm` requires that port and renders a form.
+
+```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 materialization with retention; the source and the target selector are positional
+    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']), // host methods as Calls, one to one
+  }),
+  exports: ({ own }) => ({ resolveItem: own.resolveItem }), // for features that import this definition
+  provides: ({ port, own }) => ({
+    resolve: port(resolveItemPort, own.resolveItem), // the port for whoever requires it
+  }),
+});
+```
+
+```ts
+// features/checkout/models/orderModel.ts — knows nothing about the feature
+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); // owned state; writes go only through ctx.update
+  const item = ctx.state<Item | null>(null);
+  // a dependency method of the form `(input, signal)` becomes a `Call` in one line
+  const { resolveItem } = ctx.calls(platform, ['resolveItem']);
+  const submit = ctx.call({
+    run: async (intent: Intent, { invoke, signal }) => {
+      const resolved = await invoke(resolveItem, { itemId: intent.itemId }); // the call goes through the context
+      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 — the only place that knows both sides
+const createFormFeature = defineFeature({
+  id: 'checkout.createForm',
+  imports: { platform: createFormHost, catalog: catalogCatalogFeature }, // a host by contract, a feature by definition
+  requires: { resolveItem: resolveItemPort }, // a port; the application picks the provider
+  own: ({ model, imports, requires }) => ({
+    // the dependency map resolves refs: the factory receives the materialized host value
+    order: model(OrderModel, { platform: imports.platform }, (ctx, { platform }) => createOrderModel(ctx, platform)),
+    lookup: requires.resolveItem, // inside `own` a port stays a ref
+  }),
+  // here `own` is already materialized: both the port and the model field arrived as live `Call`s
+  exports: ({ own }) => ({ lookup: own.lookup, submit: own.order.submit }),
+  provides: ({ slot, pipe }) => ({
+    // a contribution is a value, an instance factory or a pipe descriptor; `priority` and `when` go in the options
+    content: slot(orderFormContentSlot, ({ exports, model }) => ({
+      Component: CreateForm,
+      // the contribution's UI model: created per mount, and it sees the `props` of exactly that mount
+      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 }), // adapts slot props to component props
+    })),
+    toolbar: slot(
+      orderHeaderToolbar,
+      { Component: SubmitToolbarButton },
+      // a predicate of this instance: `read` records what the answer depends on, and `false` withholds the entry
+      { priority: 10, when: ({ imports, read }) => read(imports.platform.submitAllowed) },
+    ),
+    // a pipe declares its handler as a descriptor: `fold` runs on a fold, with this instance's context
+    amount: pipe(orderAmountFormatter, { fold: value => value.trim() }),
+  }),
+  when: [authorized], // the feature lives while the condition holds; without `when` it lives with the application
+});
+```
+
+```tsx
+// features/checkout/ui/createForm/contracts.ts — the UI contracts
+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 — the component imports only its own feature's contracts
+export const CreateForm = requiresModels([OrderActions])(({ itemId }: { readonly itemId: string }) => {
+  const order = useModel(OrderModel); // an `own` model: the contribution itself serves it
+  const actions = useModel(OrderActions); // the contribution's UI model: it is listed in `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} />;
+});
+```
+
+Features are collected in an application manifest, which the host can load behind a dynamic boundary. The host
+passes platform adapters through `bind` and mounts 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} />
+```
+
+What is not visible here, and must stay invisible to an author: module, fence, retire, drain, quarantine, lane-lease,
+publication barrier. All of it belongs to the runtime and its integration layer.
+
+### 2.1 The sections of `defineFeature`
+
+| Section     | Answers                                | Form                                                                                                                                                             |
+| ----------- | -------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `id`        | What the feature is called             | `'feature.entity'`, dots only, no suffixes                                                                                                                       |
+| `imports`   | What the outside gives me              | a record of `defineHostContract` contracts and other feature definitions; `optional(x)` is a weak edge, `onDemand(hostContract)` defers binding to the first use |
+| `requires`  | Which port I need                      | a record of `port` or `optional(port)`; each `requires.x` is a ref, and the `Call` appears on the instance                                                       |
+| ref vs Call | What is visible at which stage         | `own` and the outer `provides` factory see refs; `exports` and nested contribution factories see materialized instance values                                    |
+| `own`       | What I own                             | builder: `model`, `call`, `calls`, `lane`, `effect`, `event`, `resource`, `stream`, `scope`, `attach`                                                            |
+| `exports`   | What I hand to features that import me | `({ own }) => a record of Call, Readable and Resource` computed when the instance opens                                                                          |
+| `provides`  | What I offer to extension points       | `({ port, slot, pipe, register, own }) => ...`                                                                                                                   |
+| `when`      | How long the feature lives             | a list of `Condition`; empty or absent means a permanent feature                                                                                                 |
+
+Only `id` is mandatory. A stage sees only the stages before it: `imports`, `requires` → `own` → `exports`,
+`provides`. There is no `ui` section: UI enters the application as contributions.
+
+A feature may also be written as two files (D186, D207). The header keeps `id`, `imports`, `requires`, a
+`provides` of metadata — the target of every contribution with its priority, the port of every provider — with `when` and
+`body: () => import('./feature.body')`; the body file writes `defineFeature.body(header, { own, exports, provides })`
+and its loader names the export border as `FeatureBody<Exports>`, so the header never depends on the type of its own
+body. Consumers and the application import only the header: the whole topology, its cycles and its lifetime
+containment compile before a byte of the body is fetched. The body loads when an instance opens, once per feature and
+shared by concurrent consumers; a loaded body is reused by later instances, a failed load is not cached, and a close
+or a fence before the code arrives means the instance never opens at all. `defineFeature.preload(feature)` fetches
+the code without opening anything, for a host that already knows the feature is about to be needed.
+
+### 2.2 The model layer
+
+A model is the unit of a feature's owned state and behaviour. The declaration `defineModel<Shape>(id)` lives in
+`features/x/models/` or in the UI contracts and fixes a record of `Readable` and `Call`; a class as `Shape` does not
+type-check. The implementation is a factory `(ctx: ModelContext, deps) => Shape` or a class
+`implements ModelOf<typeof X>` that receives `ctx` and `deps` in its constructor. `ModelContext` has no generic
+parameter: `state`, `update`, `call`, `calls`, `lane`, `effect`, `event`, `resource`, `stream`, `scope`, `timers`,
+`cleanup`, `signal`. `ctx.calls(deps, [...], { lane, policy })` selects methods of the forms `() => Output`,
+`(input) => Output` and `(input, signal: AbortSignal) => Output`
+from the dependencies and returns one `Call` per key — the same selection and the same type inference as `own.calls`,
+plus an optional model lane and the policy every selected call is created with. A method without parameters gets
+`void` input; an optional input retains `undefined`. The second parameter must be exactly `AbortSignal` or
+`AbortSignal | undefined`, including an optional signal. Data fields, `any` signatures, unbounded rest parameters
+and signatures with a possible third argument are not selectable. A bounded tuple rest with at most two parameters
+follows the same rule. Overloads follow TypeScript's last-signature inference; use an explicit adapter when the
+desired overload differs (D244). The policy is written where the call is created — `ctx.call`, `ctx.calls`,
+`own.call` — and it holds for every caller the call allows, `context.invoke(target, input)` included (D185). `ctx.cleanup(disposer)`
+registers owned cleanup: the disposer runs in the same drain as the disposers of `effect`, `event`, `resource`,
+`stream` and `scope`, in reverse registration order, its failure goes to the `reporter`, and a call after the fence
+is a `TypeError`, as with `timers` after close. `ctx.state` returns `OwnedState<Value>`, and only that is accepted by
+`ctx.update`: a derived `Readable` does not type-check. A model declares its dependencies as its own interface and
+the feature substitutes them in `own`. The UI receives a model through `useModel(Decl)` only inside a mount of the
+contribution that granted it.
+
+**Declaration and execution (D243).** `ctx.call(options)` on the model factory context and `own.call(options)`
+declare a command; `ctx.calls(source, keys, options?)` or `own.calls(source, keys)` declares several. A command's `run` receives a different
+context: `context.invoke(target, input)` executes an existing command with the current authority, cancellation and
+lane stack. Destructuring is supported: `run: (input, { invoke }) => invoke(deps.submit, input)`. The policy remains
+on the declaration; `invoke` adds no scheduler or policy override.
+
+This is a breaking rename with no execution-context `call` alias. Migrate accesses, destructured bindings and
+custom context type annotations together. Factory methods and the types `Call` and `CallInvocation` keep their names:
+
+```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);
+```
+
+The same rename applies to existing invocation capabilities in `ModelCallContext`, `FeatureCallContext` and the
+trusted attachment execution contexts, including `ModuleAttachmentExecutionContext` passed as `step`'s `context`.
+Contexts that did not provide invocation do not gain it; callbacks keep their own documented capabilities.
+
+**Signal lifetimes (D244).** Keep the signal from the callback doing the work:
+
+| Signal                                          | Lifetime                                                                                                                                                          |
+| ----------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `ModelContext.signal`                           | The whole owned model. It is unsuitable for cancelling just one request.                                                                                          |
+| Command `run` context's `signal`                | One physical command execution. Nested `invoke` inherits cancellation, authority and the lane stack; `singleFlight` waiters still have separate logical outcomes. |
+| `Resource.load` context's `signal`              | The active load for the current target generation; replacement, refresh, retirement or owner close may abort it while the model stays alive.                      |
+| `Stream.connect` / `consume` context's `signal` | The current connection execution; replacement, retry or retirement fences that execution and drains admitted work before a successor opens.                       |
+
+`calls` always invokes a selected method with `(input, signal)` and preserves its receiver. Ordinary methods may
+ignore the extra arguments; no dummy `_signal` is required. A single parameter named `signal` is still an input,
+not an injected cancellation token. Map a client's options or extra arguments in a small ordinary adapter, such as
+`load: (input: Input, signal: AbortSignal) => client.load(input, { signal })`. There is no `Function.length`
+inspection, argument inference or additional adapter primitive. A method that ignores cancellation can keep
+working after the caller is logically cancelled. The runtime rejects late Call results and controls publication
+from retired Resource/Stream executions; it cannot stop arbitrary state writes or external side effects inside the
+method. Those need the method's own signal checks. Physical drain still waits for work that has started.
+
+The feature composes dependencies with `model(Decl, { platform: imports.platform, lookup: requires.lookup }, create)`;
+the second factory argument is a readonly map of resolved values with inferred types. Use the same map for one
+source, or `model(Decl, create)` for none. Only authentic imports and call refs of the current feature are accepted;
+optional imports retain `Readable<Lookup<…>>`. Raw host objects, port declarations, foreign refs and model refs do
+not form dependency entries. A named factory may declare its own dependency interface without seeing the feature
+context. `provides.port(SubmitPort, { from: own.order, select: order => order.submit })` selects an authentic call
+once from the materialized model before publication and adds the provider's lifetime fence, including passthrough
+calls. A local call ref still uses `port(SubmitPort, own.submit)` (D169).
+
+A contribution has two kinds of model, both declared with the same `defineModel`. `own` models live with the feature
+instance and are served to a mount automatically. A contribution's UI model lives with the mount: it is listed in the
+contribution's `models`, its factory receives the `Readable` of that mount's props as its second argument and either
+takes fields as they are (`submit: exports.submit`) or wraps them in `ctx.call` when the UI contract differs in
+input, in result shape or in the number of feature calls. There is no separate View concept.
+
+### 2.3 UI
+
+UI enters the application by one path: `provides.slot(target, { Component, props?, models? })` publishes a component,
+and `Slot` renders it inside the contributing feature's authority. Inside a contribution, `useModel` works on its
+instance's models and on the UI models the contribution declared, and above their fields sit `useCommand`,
+`useReadable`, `useSelector`, `useResource`. Slot props are typed by the target: without an adapter the component
+takes them as they are, with a `props` adapter it takes exactly the adapter's result.
+`requiresModels([...])(Component)` lists the UI models the component reads: the type checks that the contribution granted every one of them. Granting is hybrid: the `own` models of the feature are served implicitly to every component of the mount's subtree, while a per-mount UI model must be declared by the component or hook of the same module that reads it with `useModel`. The declaration belongs to each reader, not only to the contribution site (see decisions.md, D158).
+
+`opetope/require-declared-models` in `@opetope/lint` recommended checks visible `slot` contributions and model readers within one module. It resolves import aliases and local bindings, including named components. Imported implementations and dynamic declarations remain unverified; no diagnostic does not prove their requirements complete (D250).
+
+Hooks: `useModel`, `useReadable`, `useSelector`, `useCommand`, `useCommands`, `useResource`. Components: `Slot`, and
+`FeatureBoundary` from `@opetope/react/integration`, which holds a feature open and renders `fallback` or `error`.
+Both of its branches take either a node or a render callback: `children` receives the ready instance typed by the
+demand, `error` receives `{ error, retry }`, only the branch that is shown runs, and a ready consumer needs no
+second `useFeature` and no second lease (D177). A
+command through `useCommand` follows the Call’s declared policy, does not turn instance cancellation into a user-visible
+error, and holds the last outcome in `result` and `lastError`; a command has no observation mode — the state of
+somebody else's invocation is exposed by the model as a `Readable` field. Component tests use
+`renderSlot(target, { props, models, contribution })` and `command(run)` from `@opetope/react/testing`.
+
+`run` keeps its identity while the invoker is unchanged; the hook result object changes with status. Depend on `run`
+when an effect invokes the command. A consumer has no policy of its own: every `run` reaches the call, and the policy
+the call was created with decides what happens to it (D203). What stays with the consumer is what only it knows — an
+already-aborted input signal is refused as `cancelled` without reaching the call, a run of an unmounted consumer is
+refused the same way, `inFlight` is true while any run this consumer started is unsettled, and each run carries its
+own outcome, callbacks and signal. Two consumers of one call keep separate statuses.
+
+`useModel(Declaration, (model, { read }) => ({ ... }))` selects data and command consumers in one hook (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.
+The readonly inferred record maps authentic Call fields to `CommandHook`; other selected fields preserve their types.
+`read(readable, project?)` reads explicitly, deduplicates source subscriptions and applies no automatic Resource retain.
+Returned fields use `Object.is` equality; fresh nested objects are changed fields. The pure callback cannot call hooks,
+commands or side effects. Subscription replacement and command admission happen at commit, not in an abandoned
+render. Keys, aliases, local statuses and `.run` follow `useCommands`. No model creation, feature acquire or new
+scheduler is implied. `useModel(Declaration)` keeps returning the granted model, with a constant hook layout when
+selection changes. Sharing one hook is a DX choice, not a performance guarantee.
+
+`useCommands({ save: model.save, remove: other.remove })` returns a `CommandHook` at each key, with exact
+heterogeneous types (D174). Keys are local names; commands come from the granted model authority. There is no shared
+queue, transaction or busy state, and no option: the policy belongs to each call. While the key and invoker stay the
+same, `.run` is stable and the field object changes only with its own status. A fresh selection object or key reorder
+changes nothing. Removing an entry drops its consumer and status; readding creates a new one. Two aliases of one Call
+are independent consumers. Own enumerable properties (including symbols) are selected; the number of React hooks is
+constant when keys change. Only commit activates a new selection: an abandoned render leaves the committed consumers
+untouched. The single-command `useCommand` remains.
+
+Direct component props and the props adapter read the same mount-owned snapshot as model
+readers; incoming slot props publish in layout before paint, never through a state update in insertion effects.
+A retry of a `FeatureBoundary` demand belongs to its source: replacing source A with B does not make B wait for
+an unfinished retry of A (D170). `useFeature(...).retry` returns a promise that resolves when the attempt it started
+has settled, and a second call while one runs joins that attempt instead of starting another. It answers that promise
+even when the source refuses the acquisition synchronously: a refused acquisition is an attempt that ended, and the
+refusal belongs to the state the source publishes, not to the caller of `retry` (D226). The boundary shows
+`fallback` for the life of the attempt and reads the state again when it settles, so an attempt that fails with the
+same error object the host already holds brings the `error` subtree back (D198). The `retry` of the error subtree
+stays `() => void`: a host may pass it straight to `onClick`.
+
+`resource(from, target, options)` and `stream(from, target, options)` take a selector returning
+`Readable<T | null | undefined>` in both feature and model contexts. A scalar snapshot is invalid; a nullish target
+closes materialization. Retention is optional; `scoped({ capacity })` selects bounded LRU retention.
+`effect({ from, when, run })` tests `when(current, previous)` for each selected run. `calls(imports.x, keys)`
+selects host methods, the exported calls of a hard feature import, or — over `optional(feature)` — the exported calls
+of the provider that is there now: each selected call reaches the live instance and answers a `CallError` of code
+`unavailable` while nothing provides it (D187). Data of a weak edge is read with
+`fromOptional(source, select, { missing })`: `select` runs only on a `found` lookup and may return a value or the
+provider's own `Readable`, the nested readable is tracked only while the provider exists, and `missing` is the answer
+the rest of the time.
+
+### 2.4 Application and host
+
+```ts
+const authorized = defineCondition({ id: 'workspace.authorized' }); // a fact the host binds
+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', // the runtime identity of the application
+  features: [authFeature, sessionsFeature, catalogFeature], // enabled features; the world closes over imports
+  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)],
+});
+```
+
+A feature declares its own lifetime. `defineCondition({ id })` is a fact the host binds;
+`defineCondition({ from, id, select })` computes a fact from the exports of one feature, and the host has no right to
+bind such an id. `defineFeature({ when: [conditions] })` says the feature lives while all of its conditions hold; an
+empty or absent `when` is a permanent feature. `defineApplication({ id, features, reporter })` compiles the static
+topology before start: `requires ↔ provides`, `imports`, contributions. `features` is the list of enabled features,
+and the world is those plus the transitive closure of their hard imports, so a port's provider must be enabled or the
+port stays without one. Features with the same set of conditions form a condition group: it gives the activation
+order and one node in the devtools plan; a group is never declared separately. `openApplication` raises the
+application: `conditions` is a record of `Readable<boolean>` by id, typed from `Application<Features>` as the union
+of condition ids without `from`, and `imports` is an array of `bind(contract, value)`, which validates the value at
+the call site. The optional `cleanupFailure` carries the same two words as `openFeature` and defaults to `report`:
+the host that chooses `quarantine` keeps a failed cleanup as an exact frontier on `FeatureError.retryCleanup`
+instead of a report, and the devtools control port can then retry it (D182).
+
+---
+
+## 3. Public vocabulary
+
+Naming rules: `define*` declares a contract without behaviour; `use*` reads in React; `open*` raises a lifetime;
+builder methods carry no prefix; errors are `<Subject>Error` with a `code` field. A kernel word is the name of
+machinery an author does not control: `Module`, `Attachment`, `Executor`, `Authority`, `Owner`, `Blueprint`, `IR`.
+Such a word lives only in `internal`, appears in no name on a safe entry, and appears in no author-facing error text
+— those say "feature" and "instance". `module` is the unit of lowering from which the kernel assembles features and
+the children of a dynamic scope: a separate concept, not a second name for a feature. Both prohibitions are held by
+the `ci:public-surface` gate.
+
+**`@opetope/core`.** Values `computed`, `derive`, `fromOptional`, `externalReadable`, `collection`, `selectByKey`,
+`declarationId`, `defineModel`, `definePort`, `definePipe`, `defineRegistry`. Types `Readable`, `State`, `OwnedState`, `Collection`,
+`Lookup`, `Equality`, `Model`, `ModelOf`, `ModelContext`, `Call`, `Port`, `PortRef`, `Pipe`, `Registry`,
+`DeclarationId`, `Resource`, `ResourceSnapshot`, `ScopedRetention`, `LatestBackpressure`. Errors
+`CancellationError`, `FeatureError`, `ReadableError`, `DeclarationError`, `CallError`; `CallError` codes are
+`cancelled`, `closed`, `publication-rejected`, `unavailable`. `createState` and `isCancellation` live on
+`@opetope/core/internal`: an author has no pilot for state outside a model and none for recognizing cancellation by
+hand — state comes from `ctx.state`, and cancellation is read by `useCommand`.
+
+**`@opetope/runtime`.** Values `defineFeature`, `defineHostContract`, `onDemand`, `optional`,
+`openFeature`, `defineCondition`, `defineApplication`, `bind`, `openApplication`, and the policies `scoped`,
+`latest`. Types `Feature`, `FeatureInstance`, `HostContract`, `Condition`, `Application`, `ApplicationExecution`,
+`ApplicationImportBinding`, `FeatureBody`, `FeatureBodyOf`, `Resource`, `ResourceSnapshot`, `ScopedRetention`, `LatestBackpressure`, `ErrorReporter`,
+`CleanupFailurePolicy`, plus the re-exported `Call` and `Readable`. Errors `FeatureError` (re-export) and
+`ApplicationError`.
+
+**`@opetope/react`.** Values `useModel`, `useReadable`, `useSelector`, `useCommand`, `useCommands`, `useResource`, `requiresModels`,
+`Slot`, `defineSlot`, `defineSwitchSlot`. Types `SlotTarget`, `SwitchSlotTarget`, `SlotContribution`, `CommandHook`,
+`CommandOutcome`. The error `ContributionError` carries the codes `binding-invalid`, `duplicate`, `inactive`,
+`missing`: its subject is the contribution mount, which grants models and fences commands, so there are no separate
+`ModelError`, `RootError` or `ActionError`.
+
+**`@opetope/react/integration`.** `FeatureBoundary`, `useFeature`, `useFeatureRetry`,
+`FeatureBoundaryError`. **`@opetope/react/testing`.** `renderSlot`, `command`, `createScenario`, `ScenarioTimeoutError` and fixture/scenario types. There is no `useFeatureError`: a host
+that passed an error into `error` already knows it, and the boundary context stays internal to `useFeatureRetry`.
+
+**Lifecycle capabilities.** `FeatureInstance` exposes `ready` and `close()`. Closing fences immediately and joins one
+completion promise. `FeatureError.retryCleanup?: () => Promise<void>` exists only on a quarantined failure with
+retryable cleanup; test for that capability before calling. The internal term and cancellation code `retired`
+remain. Resource retry and feature-demand retry keep their own meaning. The former author names `retire`,
+`FeatureError.retry`, `effect.condition`, `required(port)` and the `scoped` option `evict` have no aliases (D168).
+
+**Inside `defineModel`.** `ModelContext` per §2.2, with `scope` reading `scope.while`, `scope.switch`, `scope.keyed`.
+
+**Inside `defineFeature`.** The sections of §2.1; the methods of `own`: `model`, `call`, `calls`, `lane`, `effect`,
+`event`, `resource`, `stream`, `scope.while`, `scope.switch`, `scope.keyed`, `attach`. For `resource`, `stream` and
+`event` the source and the carrier of type inference are positional: `resource(from, target, {…})`,
+`stream(from, target, {…})`, `event(from, subscribe, {…})`; the key order inside the options object is free. One
+option carries the same word for both: a stream requires `backpressure: latest()` and an `event` admits it. The
+methods of `provides`: `port`, `slot`, `pipe`, `register`; contributions take the target first, a value or an
+instance factory second, and options third: `slot(target, contribution, { priority, when })`,
+`pipe(target, { fold }, { priority, when })`, `register(target, entry, { priority, when })`, where `pipe`'s second
+argument is a descriptor because a bare function would be indistinguishable from the instance factory. The
+contribution factory context is `{ exports, imports, instance, model, own }`, and its `model(Decl, create)` builds
+the mount's UI model, where `create` receives `(ctx, props)`. `when` is a `Readable<boolean>` or a predicate of the
+instance — `({ exports, imports, own, read }) => boolean` — whose `read` records what the answer depends on: while
+the answer is `false` the contribution does not enter the target's `entries`. In that evaluation context `own` is
+the materialized form `exports` sees, so a model field is a `Readable` and not the ref the factory context carries.
+A `pipe` descriptor's `fold` receives that same evaluation context as its third argument —
+`(value, meta, { exports, imports, own, read }) => …` — bound to the instance once when the contribution publishes
+and called only by a `fold`, never at declaration or preload; `target.fold(value, meta, read?)` accepts the reader
+as its third parameter, so `computed({ read: read => target.fold(0, undefined, read) })` subscribes both to
+`entries` and to everything the handlers read; without a reader the handlers read the current snapshot. Contexts:
+`source`, `signal`,
+`invoke`, `update`, `timers.delay`, `timers.interval`, `cleanup`, `current`, `previous`, `emit`, `payload`.
+
+Totals: 39 value exports and 35 types across the three safe entries by the `ci:public-surface` gate, against targets
+of 40 and 60. The daily vocabulary of a feature author is about 20 words.
+
+**`@opetope/core/internal` and `@opetope/runtime/internal`**, for framework implementation and host integration:
+`defineModule`, `instantiateModule`, every `Module*` and `Attachment*`, the call kernel `defineCallTarget`,
+`createCallExecutor`, `defineCallLane`, contribution publication `publishContributions`, `bindFeatureResource`,
+`getApplicationPlan`, `createState` and `isCancellation`. The entries are bounded by actual consumption: 43 value
+exports in core and 20 in runtime, and whatever nothing imports from outside the package stays module-local (see
+decisions.md, D159). `@opetope/react` has no internal entry.
+
+---
+
+`@opetope/devtools/react` exports `defaultTheme`, a neutral standalone palette. Applications customize the panel through `DevtoolsTheme`; overrides stay scoped to the panel root (D249).
+
+## 4. Laws of the kernel
+
+Each law is proved by package tests and survives renaming.
+
+- **Ownership and the feature instance.** Everything created in `own` lives and dies with the feature instance. Every
+  attachment hangs off an import or a host contract: a feature owns no scopes, so a per-instance value arrives by
+  exactly one path — through `imports` (see decisions.md, D141). Retire first makes the instance stale and fences its commands, then notifies, then closes its children. There is no order among the attachments of one scope: they open and close as one wave, and a quarantine frontier is reported in canonical slot order (see decisions.md, D163). The order between features of different condition groups is held by the group order, not by this law. A late result of an old instance is not published.
+- **Physical drain and rollback.** Logical cancellation settles the caller promptly but does not imply that user
+  work has stopped. Drain waits for admitted work, including a pending opening and stream consumption, before
+  releasing its source. Models register rollback ownership before their factories run, including per-mount
+  contribution models. A failed factory cleans up partially created nodes. The fence closes all owned state and
+  rejects new nodes from the same context; a sibling model's `OwnedState` is not writable by that context (D170).
+
+- **Coordinated close.** A close already running on one attachment does not cancel the close of the others: a
+  coordinated fence joins that drain and reports its outcome, so one member rolling back does not cost its
+  neighbours their close.
+- **Cleanup.** The default is `report`: a cleanup error goes to the application reporter and the instance counts as
+  closed. `quarantine` is an explicit opt-in for resources with a mandatory physical release.
+- **Data.** One scheduler stabilizes `derive` and `computed`, notification happens once per transaction, and
+  `selectByKey` creates no cross-key notifications.
+- **Settled reads.** Reading an active clean node does not walk the graph: it returns the settled value, because
+  everything upstream has already published (see decisions.md, D130).
+- **Transactional activation.** A failure midway rolls back the nodes activation already reached, in reverse order,
+  and disposer failures during the rollback arrive together with the original cause.
+- **Close propagation.** `close()` on a `State` is one notification to dependent nodes, after which `derive`,
+  `computed`, `collection` and `selectByKey` answer with a `ReadableError` of code `closed` instead of the last
+  value, then stay silent; an unsubscribed derived node gets the same failure on its next read of the closed source.
+  A close is workspace even against the code that caused it: an updater that closes the state while it computes gets
+  its result refused, and the state stays closed (D201).
+- **Lookup.** `Lookup` is literal: `{ kind: 'found', value } | { kind: 'missing' }`, and the same shape projects a
+  weak edge.
+- **Calls.** `call` is `queue` by default, `parallel` is explicit, `latest` keeps one waiting place, `once` caches,
+  `singleFlight` deduplicates by key; a nested call goes only through `context.invoke`, and cancellation and the lane
+  are inherited.
+- **Latest.** A call declared `latest` runs on a lane like `queue`, and while its body runs a newer input replaces
+  the waiting one: the replaced invocation ends as a cancellation with its own callbacks and signal, and the body in
+  flight is never interrupted. Replacement stops at the lane: once another call has queued behind the waiting
+  invocation, that invocation keeps its place and the newer input waits after it. A price of 100, a submit and a
+  price of 200 on one lane therefore submit 100 and then apply 200 (D185).
+- **Event delivery.** An `event` runs one payload at a time behind a slot for one more. `backpressure: latest()`
+  gives that slot to the newest payload and reports nothing; an `event` written without the option keeps the payload
+  that reached the slot first and drops a newer `emit` with a `queue-capacity` failure record. Neither policy
+  interrupts a `run` in flight, neither holds more than one waiting payload, and closing the owner drops what waits.
+  A queue that loses nothing is a separate question (D183, D247).
+- **Command outcomes.** `useCommand` does not turn cancellation into an error and holds the last outcome: `result`
+  from the last `ok`, `lastError` from the last `failed`, `cancelled` moves neither, and starting a run clears
+  neither, so the previous failure stays readable while a retry is in flight. A missing provider and a rejected
+  publication arrive as `failed` and settle into `lastError`.
+- **Publication.** Contributions are published atomically after their owner's critical opening barrier and before
+  public `instance.ready` resolves, then withdrawn on retire;
+  contribution targets are static, so the topology compiles before start. A target holds one contribution per
+  feature key, so two live instances of one feature cannot contribute to one target at the same time.
+- **Withheld contributions.** A contribution whose `when` is `false` is published but does not enter the target's
+  `entries`, so `Slot`, `fold`, `select` and emptiness checks do not see it; a change of the value recomputes
+  `entries` in one transaction. A predicate is lowered to one computed readable of its instance before the
+  publication starts, so the paths below are the same for both forms, and an answer that is not a boolean fails
+  that read instead of publishing a truthy object as visibility (D220). Uniqueness of ids and keys is checked across every published contribution, so a
+  change of `when` can never fail validation.
+- **Publication atomicity.** A publication keeps its foreign steps outside its writes. Subscribing to `when` and
+  reading it both run before any target has touched its `entries` — the read comes after the subscription, so a source
+  that flips from inside `subscribe` is published in the state it ended in — and releasing the watcher a departing
+  entry leaves behind runs after every target of that publication is committed, so a withdrawal made from such a
+  disposer removes from the committed state instead of being undone by it. A publication reads only the `when` of its
+  own entries; every other owner keeps the visibility it was last published with, so a mandatory withdrawal reads no
+  `when` at all and an unreadable predicate cannot hold another owner's entries in a target (D225). A `when` that
+  signals while the publication projects invalidates that projection, and the affected targets are projected again; a
+  source that signals from every read fails the publication loud instead of committing what it answered before the
+  signal. A target that refuses the publication rolls back the subscriptions the earlier targets made, so a failed
+  publication leaves no listener behind, and a failed withdrawal removes what already landed. A change of `when` made
+  from inside an `entries` listener is not lost: the reentrancy guard records it and the loop publishes it.
+  A later visibility refresh also checks its exact entries and visibility revision after each getter. It discards
+  an invalidated projection before reading a removed neighbour or publishing stale entries; after 100 restarts it
+  fails with `TypeError` and releases its guard so a later stable notification can recover (D242).
+- **Feature opening and closing.** Eager definitions and lazy headers validate and snapshot the option record, imports
+  and requirements at `openFeature`, before any loader runs; later replacement of those fields cannot change the
+  instance. `close()` fences synchronously and concurrent or reentrant callers join one completion promise. A
+  loader failure, including a synchronous throw, rejects `ready` or `preload`. Closing before code arrives rejects
+  that instance's `ready` as `retired` and finishes without waiting for the shared load. The load remains available
+  to other instances and preloads; a late success cannot open the retired instance, and a failure permits retry.
+  Once materialization has started, close still drains the owned work and preserves quarantine recovery (D211).
+- **Application startup.** A close requested from a condition subscription or its disposer owns the same close
+  promise as every other caller. It fences the groups already created, releases a subscription returned after that
+  close, creates no later groups and rejects application readiness; `close()` waits for all started cleanup (D210).
+- **Ports.** A port has exactly one provider; the choice is made at application level; two providers are a topology
+  compilation error.
+- **Lifetime as conditions.** A feature declares its lifetime: it lives while all conditions of its `when` hold, and
+  an empty `when` means "as long as the application lives". Features with the same set of conditions form one group,
+  so the set, not the order, determines the owner. A condition is a desired state and not an event: the runtime
+  follows the last snapshot, so a value that flips false and true again within one turn keeps the live generation,
+  and the end of a session is expressed as a fact of the condition — a session id, say — rather than as a brief
+  false (D190).
+- **The containment law.** A hard edge is legal only when the provider's condition set is a subset of the
+  consumer's: the provider must live at least as long, otherwise the compiler refuses and points at `optional`. The
+  same law holds for a condition with `from`: the source feature must outlive whatever the condition gates. A group
+  opens in the canonical order of its features and closes in reverse, and a condition computed from a closed feature
+  reads as `false`.
+- **The weak edge.** `optional(x)` in `imports` and `optional(port)` in `requires` are one word with one meaning: an
+  edge on which the consumer may outlive the provider. Exports arrive as a `Readable<Lookup<Exports>>` projection,
+  resources behind it are unreachable while the projection says `missing`, and a call on a weak port settles as a
+  `CallError` of code `unavailable` while no live provider exists — an error, not a cancellation. The reason for
+  absence is not distinguished: provider absent from the application, or its condition group closed, look the same.
+- **Weak-edge sugar.** The two halves of a weak edge have one word each: `calls(imports.x, keys)` for the exported
+  calls of the provider and `fromOptional(source, select, { missing })` for its data. Both read the provider at the
+  moment they are used, so a new instance is followed without rebuilding anything, an invocation in flight ends with
+  the provider's own fence, and nothing of a missing provider is held (D187).
+- **Weak-edge inertness.** A weak edge does not pull its provider into the application's world and never affects
+  activation order: the provider opens with its own condition group, whoever imports it. The containment law holds
+  for hard edges only, and the compiler message on its violation points at `optional` (see decisions.md, D105).
+- **Exports.** `exports` is computed when the instance opens, from an already materialized `own`, so the record
+  carries live values: the `Call`, `Readable` and `Resource` of that instance, not a snapshot and not a ref. A whole
+  model is not exportable — only its fields, because a model is a record of values, not a value. Owned state leaves
+  narrowed to `Readable`: the writer stays with the owner, and the type enforces it.
+- **Hard-edge visibility.** On a hard edge the provider opens before the consumer and the consumer closes before the
+  provider, so the consumer never sees closed values. After the provider retires an exported `Readable` is closed at
+  the fence, so a subscriber hears it once and a read yields a `ReadableError` of code `closed`.
+- **UI authority.** `useModel` resolves only models granted by the contribution mount: the models of its own instance plus the UI models the contribution declared. Granting is hybrid: `own` models reach every component of the subtree implicitly, a per-mount model is declared by the component or hook that reads it, and the lint rule holds that boundary because one mount frame cannot tell nested readers apart. There is no tree walking and no access to other features; the frame is stable, and a model update does not change Context.
+- **React compatibility.** `@opetope/react` supports React `>=19.0.0 <20`; the Devtools UI and browser integration support matching React/React DOM versions in that range. Release acceptance installs separate React/React DOM and type-package cohorts at `19.0.0` and at the contributor toolchain versions, then checks NodeNext/Bundler types, model-backed rendering, commands, demand and Devtools mount/unmount on Node 20.19+ (D251).
+- **Mount lifetime.** The instances of the `models` plans are created in commit and never in render (D188): the first
+  pass of a contribution renders nothing, a layout effect keyed by the identity of the contribution builds the mount
+  from the props that committed, and React flushes that one extra synchronous render before paint. A render that is
+  thrown away — the second StrictMode copy, an abandoned concurrent pass, a subtree suspended by a lazy sibling —
+  creates nothing at all, so nothing has to be swept, adopted or rebuilt, and a child layout effect never sees a
+  closed mount.
+- **Structural readers.** `Readable`, `Resource` and the demand source are structural contracts, so a host may
+  implement one with an object whose members are methods. Every hook calls them through the object it was handed and
+  never as a detached function, so an adapter may rely on its own `this` (D199).
+- **Committed mounts.** A committed contribution identity owns its model bundle. StrictMode effect replay and
+  Suspense hide/reveal reuse that live bundle and state; disconnecting layout effects does not retire it. Actual
+  identity replacement or unmount releases it once. A hidden unmount releases the bundle in a microtask because
+  React has already disconnected its layout effects; readable notifications never run in insertion effects
+  (D209). After release a call is a cancellation, not a product error.
+- **One Call, one command.** A mount holds one command per distinct Call, however many model fields name it: two
+  fields of one model are aliases, so they share the record, the activation and the fence (D197). Two models of one
+  mount that declare the same model id are still a duplicate. A status stays local to its consumer: `useCommand` and
+  every key of `useCommands` keep their own `inFlight`, `result` and `lastError`, even when they name one Call.
+- **Errors.** One class per author-vocabulary subject, with the state in a `code` field: `FeatureError`, `CallError`,
+  `ReadableError`, `ContributionError`, `ApplicationError`, `DeclarationError`. Cancellation is a marker keyed by
+  code, not a place in a hierarchy: it is true for `CallError` with `cancelled` or `closed`, `FeatureError` with
+  `retired`, and `ContributionError` with `inactive`. `CallError` with `unavailable` or `publication-rejected`
+  carries no such brand: those are an answer to the product, not an abandoned call. `FeatureBoundaryError` with code
+  `missing` obeys the same law and lives in `@opetope/react/integration`, outside the three safe entries' budget.
+- **Boundaries.** `@opetope/*` does not import application hosts, their adapters or UI design systems. A production file under
+  `@opetope/*/src` is at most 600 lines. Hot paths use direct calls without `Reflect.apply`, bind wrappers or
+  argument-array allocation; they create no `Error` on success and add no defensive freeze inside loops. New
+  per-operation records require focused allocation measurements within the budgets. Hostile-boundary validation
+  happens where external data enters.
+
+---
+
+Reentrant callbacks preserve these laws (D218): application close fences ready members of a still-opening condition
+group, including a member returned after close. Resource abort/getter/key callbacks cannot overwrite a newer selection
+or restore state after fence. Latest admission reserves its waiter and lane position before replacement notifications;
+reentrant close/retire settles that waiter. Physical cleanup still follows dependency order.
+
+Stream target selection follows the same freshness rule (D219): if a target getter or key callback synchronously
+causes a newer selection, the older callback cannot replace it after returning. Selection freshness is separate from
+request-key equality, so a newer target with the same key remains available to a subsequent refresh.
+
+## 5. Gates and budgets
+
+Performance and size budgets are ratchets: raising a limit must not hide a regression. A public-vocabulary addition
+within the target requires an explicit decision and a compile-checked application pilot; the gate records the
+authorized change, as for D187 and D207.
+
+### 5.1 `ci:public-surface`
+
+Counts the author-visible vocabulary of the three safe entries — `opetope/core/src/index.ts`,
+`opetope/runtime/src/index.ts`, `opetope/react/src/index.ts` — against the current budget in
+[public surface contract](spec.md#5-gates-and-budgets), with the totals and targets of §3. Names are
+deduplicated across entries, so a re-export costs nothing.
+
+The same gate holds four further checks over the internal entries `core/src/internal.ts`, `runtime/src/internal.ts`,
+`react/src/integration.ts` and `react/src/testing.tsx`:
+
+| Check               | What fails                                                                                                                                                                   |
+| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Retired words       | `[Tt]ask[A-Z]`, `^Task$`, `[Ss]ignal[A-Z]`, `Domain[A-Z]`, `^Domain`, `View[A-Z]`, `^Setup[A-Z]` in any position of an identifier on an internal entry                       |
+| Signature leaks     | a public value whose return type names an internal-only type, outside a three-entry allowlist (`onDemand`, `optional`, `selectByKey`)                                        |
+| Nested kernel words | a walk of depth 4 over the properties and call results of every public type, refusing `Module`, `Attachment`, `Executor`, `Authority`, `Owner`, `Blueprint`, `IR`            |
+| Author messages     | a string or template literal reaching an author error class that says module, attachment, executor, authority, owner, blueprint, generation, lifetime, task, setup or domain |
+
+The author error classes are `ApplicationError`, `CallError`, `ContributionError`, `DeclarationError`,
+`FeatureError`, `ReadableError`.
+
+### 5.2 `ci:size-limit`
+
+Five budgets, and all five measure what an author sees. The fixtures are compiled consumers, not whole packages,
+except for `@opetope/react`, which is measured on `dist`.
+
+| Budget                       | Package            | Limit  |
+| ---------------------------- | ------------------ | ------ |
+| `author primitives consumer` | `@opetope/core`    | 1.1 kB |
+| `data layer consumer`        | `@opetope/core`    | 4.9 kB |
+| `public feature consumer`    | `@opetope/runtime` | 32 kB  |
+| `application graph consumer` | `@opetope/runtime` | 48 kB  |
+| `dist/**/*.js`               | `@opetope/react`   | 18 kB  |
+
+The `feature-consumer.ts` fixture holds the current form: a condition in `when`, a weak import and a weak port
+through `optional`, live `exports`, and `port`, `register` and `pipe` contributions. `public feature consumer` is dominated by the feature runtime itself, not by how richly the fixture is composed: the minimal possible feature — one host contract, one `calls`, one `openFeature` — already weighs most of the budget, and removing `resource`, `model`, `port` or `register` moves the weight by tens of bytes, because the feature runtime graph is nearly monolithic.
+
+npm artifacts use minified ESM with `keepNames: false`, preserve `.d.ts` declarations, and ship source maps with
+`sourcesContent` for the original TypeScript (D254). Reflected function and constructor names are not stable API;
+explicit declaration IDs, public error names/codes and `instanceof` identity remain intact. Maps support source
+navigation and expose the implementation. Smaller raw JavaScript does not guarantee smaller tarballs or final
+application bundles; see [release artifacts](releases.md#published-artifacts).
+
+### 5.3 Application build verification
+
+Application bundle budgets and chunk placement belong to the consuming host. When an application loads its
+manifest or feature UI dynamically, its build verification checks that the intended chunks exist and that code
+intended for deferred loading is absent from the initial page chunks. A source-level dynamic import alone does not prove the produced
+bundle preserves that boundary. Package size fixtures measure framework consumers; the host also measures its
+complete application bundle.
+
+### 5.4 `ci:perf-memory`
+
+Runs workloads at sizes 1, 100 and 10 000 (application: 1, 100 and 1 000) against
+`perf-memory-budgets.json`, schema 11. The gate validates the reference baseline's schema; numeric enforcement
+uses absolute caps and within-run scaling guards, not a comparison with its historical timing values.
+Node `--expose-gc` is required.
+
+Each workload and size completes one full warmup, three timing passes and three separate memory passes.
+`results.*.*.durationMs` is median wall time around the complete workload: harness setup, awaited cleanup and
+natural GC remain included. Timing callbacks for heap sampling and the measurement harness are no-ops;
+forced collection before each pass finishes before the clock starts. Instrumentation time is not subtracted
+from a mixed measurement. Memory passes preserve post-GC sampling, the baseline after harness setup and the
+final post-cleanup collection; peak-live and retained memory take the maximum of three passes.
+`timingSamples` and `memorySamples` retain all values, including `instrumentedDurationMs` and probe counters.
+Every pass must have a finite checksum matching the warmup and valid measurements; errors fail without retries.
+
+Schema 11 replaces the mixed timing method of D252. The 500 ms command and 1 200 ms application caps, all other
+numeric budgets, sizes and workload bodies are unchanged. Old schema 10 timing numbers are not comparable;
+a fresh full reference is recorded explicitly. Lower measured time after removing probes is not a runtime
+speedup. This separation applies to `results`; separately named allocation, adapter, graph and listener
+workloads retain their documented measurement methods (D253).
+
+`allocationRate.*.estimatedAllocatedBytesPerOperation` uses V8 Poisson sampling with a 16 384-byte mean interval,
+including objects collected by minor and major GC. It reports the median of three passes and includes measurement
+overhead, excluding external backing stores; it is an estimate, not exact accounting. With zero samples, the gate
+checks the 95% upper bound `-log(0.05) * samplingInterval / operations`. GC observation drains two event-loop turns
+and filters by the workload window; a 500 000-object calibration checks collected allocations independently of
+retained heap. `peakLiveBytesPerOperation` measures live heap after GC, not allocation rate. A baseline is written
+only after successful enforcement (D172).
+
+The saturated CallLane case uses the production queue at 1k, 10k and 100k pending requests. It checks FIFO drain
+and arbitrary cancellation of alternating interior entries; enqueue time is separate from drain/cancel, with a
+median of five passes and a per-operation growth guard. Browser verification separately creates a real application
+edge and holds consumer cleanup pending to prove that its provider remains physically open.
+
+`applicationGraphCompile` separately times `defineApplication` on chain, star, grouped and independent graphs
+with 256, 1 024 and 4 096 features. Definitions are built outside timing; two warmups precede seven samples. Each
+shape has a 100 ms cap at 4 096 features and a 3× per-feature growth guard, with a 1 ms timing floor. This schema 9
+addition measures application compilation without changing the allocation measurement or existing caps (D213).
+
+`hotPathScaling` adds batch/append/withdraw in one contribution target at 2k/4k/8k/16k entries,
+alternating `latest` and control `queue` admission behind a blocked shared lane at 1k/2k/4k/8k pairs,
+and idle inspection reads at 256/1 024/4 096 features, both empty and with a host import per feature.
+It reports the median of five samples after two warmups, excluding setup, forced GC and cleanup.
+Publication results, blocked execution, cleanup and the idle inspection sequence are checked. Each shape
+has an absolute cap at its largest size and a 3× per-operation growth guard with a 1 ms small-size floor (D245).
+The gate requires every declared size and exactly five finite samples per row, and verifies the reported median.
+
+Perf and TypeScript gates validate all required numeric budget fields against an independent schema before
+workloads run. Missing or unknown keys and non-numeric, negative or non-finite limits fail; enforced comparisons
+also reject missing measurements. With `--enforce --write-baseline`, a failed verdict leaves the previous baseline
+untouched; a successful report replaces it atomically. `ci:gate-config` checks these failure paths (D245).
+
+Budget keys and the shape of each group:
+
+| Group                     | Keys                                                                                                                                                           |
+| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `workloads`               | `command`, `definitionCompile`, `reusedDefinitionLifecycle`, `contribution` — each with `durationMsAt10k`, `peakLiveBytesPerOperationAt10k`, `retainedMbAt10k` |
+| `applicationGraphCompile` | chain, star, grouped and independent graphs: `medianMsAt4096` 100, `perFeatureGrowthFactor` 3                                                                  |
+| `hotPathScaling`          | each of seven shapes: `medianMsAtLargest` 50 for contributions, 150 for admission/inspection; `perOperationGrowthFactor` 3                                     |
+| `listenerMultiplicity`    | `contributionDurationMsAt10k` 3 000, `callDurationMsAt10k` 3 000, `peakLiveBytesPerOperationAt10k` 32 768, `retainedMbAfterUnmountAt10k` 14.5                  |
+| `coreData`                | `graph`, `leaseChurn`, `settledRead` — the last with `microsecondsPerReadAtDepth1000` 1 and `depthGrowthFactor` 3                                              |
+| `allocationRate`          | `command` 5 120, `contribution` 3 072 bytes per operation at 10 k, `unobservedWrite` 8 bytes per operation at 100 k                                            |
+| `adapterDepth`            | modes `syncPrimitive`, `plainObject`, `nativePromise`, `customThenable`, `neverSettlingCancel`                                                                 |
+| `lifecycleStepDepth`      | `sync` and `async`, each with open, close, per-step bytes and retained MB at 1 000                                                                             |
+| single-shape groups       | `cleanupRetry`, `coldInternalImport`, `mailbox`, `readableSelector`                                                                                            |
+
+`workloads.contribution` publishes and withdraws 10 000 contributions under 1 000 ms of full-workload timing and 16 384 peak-live bytes per operation;
+`workloads.command` holds 2 048 peak-live bytes per operation at 10 k. `listenerMultiplicity` asserts the listener contract: the call controller carries no subscription member (`getSnapshot`/`subscribe` are absent, exactly `activate`, `close`, `diagnostics`, `run` remain — a command is invoked, not watched, see decisions.md, D162), a mounted `useReadable` holds exactly one listener on its `Readable`, and zero after unmount. `coreData.settledRead` reads an active clean chain 20 000 times at depths 1,
+100 and 1 000 under two budgets: one microsecond per read at depth 1 000, and growth of no more than 3× from depth 1
+to depth 1 000.
+
+### 5.5 `ci:type-stress`
+
+Compiles three generated fixtures — `large-feature-01`, `-20`, `-40` — with `--extendedDiagnostics` and probes the
+language service on each. Schema version 4; the gate compares against a baseline of the same schema, and
+`type-stress-budgets.json` states per slice which numbers are `enforced` and which are `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 |
+
+**The timing rule (D224):** every millisecond in this gate is informational. Each one is printed as
+`actual of reference` and stops nothing, including the two ratchets built on time — the check time against twice its
+recorded baseline and the 40-section check time against `max(2.75 × the 20-section check time, 1 000 ms)` — because
+the same fixture swings around them on a loaded machine with no line changing. What the code decides on its own is
+what the gate enforces: instantiations against the table and against `1.15 ×` the recorded baseline, compiler memory,
+language-service RSS, the shape of the diagnostic cascade, and the declared surface of a slice against the baseline
+it was recorded from.
+
+### 5.6 `ci:browser-floor`
+
+Two passes over the production sources of `core`, `runtime` and `react`, excluding tests. The declared floor is
+Chrome 82, Firefox 110, Safari 15, iOS 15, Android 82.
+
+The surface pass resolves every member access, global constructor and global function against the TypeScript lib
+declarations and refuses anything above the floor — `Object.hasOwn`, `Promise.any`, the `AbortSignal` extras,
+`AbortController.abort(reason)`, `String.prototype.at`/`replaceAll`, the newer array methods, `Error.cause`,
+`Error(options)`, `AggregateError`, `FinalizationRegistry`, `WeakRef` — outside two audited allowances:
+`core/src/abort-compat.ts` for the abort helpers and `core/src/platform-compat.ts` for `AggregateError`.
+
+The raw-dist pass transforms every emitted `.js` file with esbuild targeting `chrome82`, `firefox110` and `safari15`
+and fails on the first byte where the transform differs from the shipped output.
+
+### 5.7 `ci:inspection`
+
+The observation boundary validates `ringCapacity` as a non-negative safe integer before attaching (default 256;
+zero retains snapshots but no delta history). Application diagnostic ids use the `application:` namespace, so
+equal application and feature declaration ids cannot collide. Optional `cause.at` is a non-negative integer
+within the Date domain, at most `8_640_000_000_000_000` epoch milliseconds. An activity replacement is a frame
+change even when graph operations are empty (D242).
+
+Runs the executable acceptance kit `assertInspectionSessionContract` from `@opetope/devtools/testing` against the
+real `@opetope/runtime` producer, on a fixture application with a provider feature, a consumer feature carrying a
+weak import, a weak port, a hard port and a `pipe` contribution, and one host-bound condition. The corpus is real
+transactions: a condition change is the one transaction the runtime commits synchronously, so a synchronous kit sees
+exactly that while everything else has already landed. Exactly one check may be marked `skipped` — the dropped-frame
+resync, which the harness cannot force and which the runtime's own ring test covers. A second skip fails the gate.
+After the kit the fixture drives the two facts of D167 on its own harness: it flips the `when` of one contribution
+both ways and expects `withheld` and `published` back, then closes the application while its instances are live and
+expects no live instance, no live contribution and a closed group. Any failed check fails the gate, not only a second
+skip. It then drives the control port of D176 on a live group with a dependent: suspend must apply, show
+`force-inactive` on the group and take the dependent with it, resume must clear both, an unknown condition and a
+healthy instance must be refused with data, and `close()` must release the override. The gate lives in
+`tooling/stress` so the runtime keeps no dependency on devtools; the one edge in the other direction is the devtools
+attach seam, which opens both ports on behalf of a host (D248).
+
+### 5.8 `ci:docs` — decision citations
+
+Every `Dnnn` in `opetope/**/src` and `tooling/stress/scripts/*.mjs` must resolve to a
+`### Dnnn —` heading in `docs/decisions.md`. That is what makes the archive's promise — numbers are stable, existing
+rows are not edited — checkable rather than merely stated: code is the reason the numbers cannot move.
+
+Review finding codes (`L3-F17`, `R1-1`) are refused in the same sources; the gate covers `L<digits>-F<digits>`
+and `R<digits>-<digits>`. They name a row of a report the reader of the code
+does not have; a finding worth keeping in a comment is either a decision, and cites one, or a piece of reasoning, and
+says it in words. Every package has been through that pass, so the ratchet of recorded counts is empty and a code is
+now a plain error wherever it appears.
+
+## 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.
+
+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 retention 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 graph/frame schema is `/3`, with optional `opetope.runtime-activity/1` snapshots. 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: `/2` readers reject the new revision. Activity identifies the execution,
+actual feature generation, physical Calls, exact current lane blockers, registered resource leases and load attempts.
+Host demand and UI models are unknown; stream observation covers state, not physical load identities. `freshness`
+and `truncated` distinguish a complete live view from a partial or detached one. A closed session is stale;
+`closed: true` requires successful physical application drain. 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.