@opetope/lint 0.12.0 → 0.12.1

package/README.md

@@ -1,67 +1,20 @@
-# @opetope/lint
-
-ESLint rules for the code an Opetope author writes. The plugin holds only what a syntactic check can prove about a
-declaration: shapes that compile and run, yet say something other than what their author meant. What the type
-checker, the runtime and dead-code analysis already answer stays with them (see [`../docs/decisions.md`](https://www.npmjs.com/package/@opetope/runtime), D227).
-
-The package depends on no other `@opetope/*` package and reads no types, so a host can lint sources it has not
-built yet.
-
-<!--examples
-import { derive } from '@opetope/core';
-import type {
-  Command,
-  ModelCommandContext,
-  ModelContext,
-  ModelStateWriter,
-  OwnedState,
-  Readable,
-  ResourceData,
-} from '@opetope/core';
-import { defineModel } from '@opetope/core';
-import { defineSlot, requiresModels, useCommand, useModel } from '@opetope/react';
-import { useEffect } from 'react';
-
-type Quote = Readonly<{ bid: number; pair: string }>;
-type Payload = Readonly<{ amount: number }>;
-/**
- * `kind` is a plain string on purpose: an updater that spreads the previous value and writes a string literal into a
- * field typed as a union of literals widens that literal and stops compiling, which is a defect of the writer's own
- * signature rather than of this example (D419).
- */
-type Sessions = Readonly<{ items: readonly string[]; kind: string }>;
-
-declare const amount: number;
-declare const busy: OwnedState<boolean>;
-declare const context: ModelContext;
-declare const ctx: ModelContext;
-declare const frames: Readable<string>;
-declare const host: Readonly<{ send(input: Payload, signal: AbortSignal): Promise<void> }>;
-declare const label: Readable<string>;
-declare const sessions: OwnedState<Sessions>;
-declare const total: OwnedState<number>;
-declare const update: ModelStateWriter['update'];
-
-const FormActions = defineModel<{ readonly submit: Command<void, void> }>('example.form.actions');
-const FormSlot = defineSlot('example.form.slot');
-declare const createActions: (context: ModelContext) => import('@opetope/core').ModelOf<typeof FormActions>;
-declare const Screen: Readonly<{ load: Command<void, void>; unload: Command<void, void> }>;
--->
+# `@opetope/lint`
+
+ESLint rules for the Opetope authoring and layer boundaries. The rules guide model writes, feature declarations, hook dependencies and imports; they do not replace type checking or runtime validation.
 
 ## Installation
 
 ```sh
-npm install --save-dev @opetope/lint 'eslint@^9' '@typescript-eslint/parser@^8'
+npm install --save-exact --save-dev @opetope/lint
 ```
 
-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
 
-## Usage
+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.
 
 ```js
 // eslint.config.mjs
@@ -75,824 +28,93 @@ export default [
 ];
 ```
 
-The plugin is both the default export and the named `opetopeLint`. The configuration registers it under the
-namespace `opetope`, so a rule is named `opetope/enabled-predicate`. Parsing requires `@typescript-eslint/parser`;
-both it and `eslint` are peer dependencies.
-
-## Configs
-
-### `recommended`
-
-Every rule that holds wherever Opetope is written: `enabled-predicate`, `define-feature-property-order`,
-`require-literal-id`, `id-naming`, `no-internal-imports`, `no-snapshot-read-in-render`, `no-snapshot-in-update`,
-`no-redundant-const-tuple`, `no-command-in-deps`, `prefer-effect-current`, `no-write-after-source-write`,
-`capture-command-cleanup`, `require-declared-models` and `no-retired-vocabulary` as errors. A rule that needs to know where a host keeps its
-files is off here and arrives through `layers`; `prefer-model-selection` is off because the number of hooks a
-component may keep is a taste a project settles for itself.
-
-`configs.recommended.rules` in full, which is also what `@opetope/lint/oxlintrc.json` ships:
-
-| Rule                            | `recommended` | Turned on by                                |
-| ------------------------------- | ------------- | ------------------------------------------- |
-| `capture-command-cleanup`       | `error`       |                                             |
-| `define-feature-property-order` | `error`       |                                             |
-| `id-naming`                     | `error`       |                                             |
-| `layer-placement`               | `off`         | `layers({ integration, models, ui })`       |
-| `no-command-in-deps`            | `error`       |                                             |
-| `no-internal-imports`           | `error`       | also scoped by `internalImports({ allow })` |
-| `no-redundant-const-tuple`      | `error`       |                                             |
-| `no-retired-vocabulary`         | `error`       |                                             |
-| `no-snapshot-in-update`         | `error`       |                                             |
-| `no-snapshot-read-in-render`    | `error`       |                                             |
-| `no-subscribe-outside-models`   | `off`         | `layers({ models })`                        |
-| `no-write-after-source-write`   | `error`       |                                             |
-| `prefer-effect-current`         | `error`       |                                             |
-| `prefer-model-selection`        | `off`         | the project, with its own `threshold`       |
-| `require-declared-models`       | `error`       |                                             |
-| `require-literal-id`            | `error`       |                                             |
-| `enabled-predicate`             | `error`       |                                             |
-
-The three `off` rules are the three that need something only the project knows: which directories are which layer,
-and how many hooks one component may keep.
-
-### `layers`
-
-`opetope.configs.layers({ integration, models, ui, tests })` takes the globs of a project's own layers and returns
-the configuration each of them earns. A layer without globs is a layer this project does not have, and it produces
-nothing; a file no glob claims is placed by nobody.
-
-```js
-...opetope.configs.layers({
-  integration: ['src/features/*/integration/**/*.{ts,tsx}'],
-  models: ['src/features/*/models/**/*.ts'],
-  ui: ['src/features/*/ui/**/*.{ts,tsx}'],
-}),
-```
-
-`integration`, `models` and `ui` each turn on `layer-placement` for their files. `models` also turns on
-`no-subscribe-outside-models` for every source file and steps aside in that layer and in `tests`, which defaults to
-`['**/__tests__/**', '**/*.spec.ts', '**/*.spec.tsx']`. A subscription is covered even in a file no layer claims,
-because forgetting one is how a subscription outlives its reader.
-
-### `internalImports`
-
-`opetope.configs.internalImports({ allow, files })` configures `opetope/no-internal-imports` across JavaScript and
-TypeScript, including `.mjs` model tests. The rule is already enabled by `recommended`; this helper is useful for
-scoping it or naming trusted library implementation and host integration files. `allow` explicitly switches off
-only this rule for those files. Place the helper's blocks **after** `recommended`: a later `recommended` block
-re-enables the rule, including for the allowed files. Other project restrictions stay intact.
-
-```js
-export default [
-  opetope.configs.recommended,
-  ...opetope.configs.internalImports({ allow: ['src/bootstrap/**/devtools.ts'] }),
-];
-```
-
-The dedicated rule never changes `no-restricted-imports`. The former `internalImportPattern` export is removed:
-enable this rule or use the helper instead of merging an Opetope pattern into the host's restrictions (D261).
-
-## Rules
-
-### `no-internal-imports`
-
-Application code and tests import public Opetope entries. The rule rejects `@opetope/*/internal` and its deeper
-paths in imports, re-exports, literal `import()` calls, unshadowed `require()` calls, TypeScript import types and
-`import = require`. It includes type-only imports; an internal type is still coupled to the private ABI.
-Use `runCommand` from `@opetope/core/testing` to run a real model Command, `openModel` from `@opetope/runtime/testing` to open one without a feature, and `command` from `@opetope/react/testing` to construct a fixture Command.
-Tests do not receive an automatic exception. Trusted library implementation or host integration can use an explicit
-file override; the rule has no autofix because the correct public replacement depends on the imported operation.
-
-**The boundary.** This is a syntactic check of literal module paths and templates without substitutions. It does
-not resolve aliases, computed import paths, re-export graphs or custom loaders. A locally shadowed `require` is not
-treated as Node's loader. Apply the config to every JavaScript/TypeScript source and test glob the project uses.
+## Documentation
 
-### `enabled-predicate`
+The [reference](../runtime/docs/reference/lint.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.
 
-A contribution's `enabled` answers the visibility fact of this instance, not the source that carries it (D220). The
-rule reads the `enabled` of a `slot`, `pipe` or `register` contribution, and any `enabled` whose function
-destructures the evaluation context `{ exports, imports, own, read }`, and reports three shapes:
+For a contributor checkout, use `npm run ci:type --workspace @opetope/lint` and
+`npm run ci:test --workspace @opetope/lint` where provided. The root `npm run check` performs full acceptance;
+[contributor commands](../runtime/docs/maintainers/contributing.md) describe the build and package checks.
 
-| Written                                       | Reported                                                                         |
-| --------------------------------------------- | -------------------------------------------------------------------------------- |
-| `enabled: ({ imports }) => imports.x.allowed` | returns a source; fixed to `({ imports, read }) => read(imports.x.allowed)`      |
-| `enabled: async ({ read }) => read(x)`        | a predicate answers synchronously; no fix                                        |
-| `enabled: () => allowed`                      | a `Readable<boolean>` is passed as `enabled` directly, without a wrapper; no fix |
+<a id="opetopelint"></a>
+[See @opetope/lint](../runtime/docs/reference/lint.md).
 
-The fix wraps the returned member expression in `read(...)` and adds `read` to the destructured context when it is
-absent. A named context is read through itself: `context => context.imports.x.allowed` becomes
-`context => context.read(context.imports.x.allowed)`.
+<a id="usage"></a>
+[See Usage](../runtime/docs/reference/lint.md#lint-usage).
 
-**The boundary.** The rule reads shapes, not types. `({ read }) => read(counter)` over a non-boolean source stays a
-type error, and so does a `read` of something that is not a `Readable`. Where a member access of the evaluation
-context is a plain value rather than a source, the predicate cannot change its answer, and the rule reports it as
-one written for a source; hoist that decision out of `enabled`, or silence the line. A `when` is a different field
-and is left alone wherever it stands — the source value of `scope.while` — and the change filter of an effect is not
-a `when` at all: it is `filter`, and D379 gave it that name so one word would not answer two questions.
+<a id="configs"></a>
+[See Configs](../runtime/docs/reference/lint.md#configs).
 
-### `define-feature-property-order`
+<a id="recommended"></a>
+[See `recommended`](../runtime/docs/reference/lint.md#recommended).
 
-A feature declares its sections in one order: `imports`, `requires`, `own`, `exports`, `provides`, `when`, and the
-`body` loader that replaces the last three stages (spec §2.1, D186). The identity is not among them — a feature
-names itself with its first argument (D280). The order is the reading order of the declaration — the edges, the
-stages, then the lifetime and the loader — so a reader finds a section by position, and a key sorter can be
-configured to hold the same order instead of a second one.
+<a id="layers"></a>
+[See `layers`](../runtime/docs/reference/lint.md#layers).
 
-The fix reorders the properties. It stands down when a comment sits between two sections, because such a comment
-belongs to neither and reordering would move it away from the line it explains; a comment inside a section travels
-with it. An object with a key that is not a section, or with a spread, is left to the type checker.
+<a id="internalimports"></a>
+[See `internalImports`](../runtime/docs/reference/lint.md#internalimports).
 
-### `no-redundant-const-tuple`
+<a id="rules"></a>
+[See Rules](../runtime/docs/reference/lint.md#rules).
 
-`derive` takes its tuple of sources as a `const` type parameter, so `[left, right]` infers its own tuple and the
-selector already sees exact values. The `as const` written beside it states what the signature already states
-(D279, D309):
+<a id="no-internal-imports"></a>
+[See `no-internal-imports`](../runtime/docs/reference/lint.md#no-internal-imports).
 
-```ts
-const summary = derive([total, label], (value, suffix) => `${value} ${suffix}`);
-```
-
-The rule reads the first argument of a `derive` resolved to `@opetope/core`, and only where that argument is an
-array literal carrying `as const`. The fix removes the assertion and nothing else. It stands down when a comment
-sits between the tuple and the assertion, because such a comment belongs to neither and the removal would take it
-along.
-
-**The boundary.** An assertion written anywhere else is left alone: on one element of the tuple, where it says
-something about that element; on the result of the selector; on the options record; and on the single-source form,
-whose argument is not a tuple at all. `as Sources` is a different assertion and says something else. The import is
-resolved within one module — a local alias, a `const` that holds the import and a namespace binding all reach the
-same export — and, unlike `no-command-in-deps`, this rule recognizes the import from `@opetope/core` and nothing
-else: a re-export through a host's own barrel it does not see. That is the deliberate price of a safe fix. This
-rule rewrites code, and a host's own `derive` has no `const` type parameter to make the assertion redundant, so
-removing it there would change the inferred types in silence.
-
-### `require-declared-models`
-
-A component that reads a per-mount UI model declares that model with `requiresModels`. Owner models remain
-available to the contribution subtree without this declaration (D158, D250).
-
-```tsx
-import { defineFeature } from '@opetope/runtime';
-import { requiresModels, useCommand, useModel } from '@opetope/react';
-
-const Form = () => {
-  const submit = useCommand(useModel(FormActions).submit);
-  return (
-    <button disabled={submit.inFlight} onClick={() => void submit.run()}>
-      Submit
-    </button>
-  );
-};
-const DeclaredForm = requiresModels([FormActions])(Form);
-
-defineFeature('example.form', {
-  provides: ({ slot }) => ({
-    form: slot(FormSlot, ({ model }) => ({
-      Component: DeclaredForm,
-      models: [model(FormActions, createActions)],
-    })),
-  }),
-});
-```
+<a id="enabled-predicate"></a>
+[See `enabled-predicate`](../runtime/docs/reference/lint.md#enabled-predicate).
 
-The rule checks contributions passed to the `slot` capability of a visible `defineFeature` or
-`defineFeature.body` `provides` callback. A local component receiving UI models must declare its requirements;
-each visible component or hook that reads one of those models declares its own list. Wrapping a parent does not
-declare the requirements of a nested function.
+<a id="define-feature-property-order"></a>
+[See `define-feature-property-order`](../runtime/docs/reference/lint.md#define-feature-property-order).
 
-Named and namespace imports, import aliases, local aliases, a named `provides` context, and both inline and named
-components are recognized. Bindings are compared within their lexical scopes; an unrelated local `useModel`,
-`requiresModels` or `slot` does not become an Opetope API by sharing its name. Named APIs from relative re-exports
-are recognized by their exported names, without reading the other file.
+<a id="no-redundant-const-tuple"></a>
+[See `no-redundant-const-tuple`](../runtime/docs/reference/lint.md#no-redundant-const-tuple).
 
-**The boundary.** Analysis stays within one module and follows visible local declarations and factory returns.
-Arbitrary objects with `Component` and `models` are not contribution sites. Imported component implementations,
-dynamic model lists and opaque helpers remain unverified: silence is not proof that their model requirements are
-complete. Model references must be locally visible identifiers or aliases; the rule does not inspect types or walk
-the rendered React tree. It has no autofix, because choosing which model a component should read is an authoring
-choice. Types and runtime authority checks continue to apply.
+<a id="require-declared-models"></a>
+[See `require-declared-models`](../runtime/docs/reference/lint.md#require-declared-models).
 
-### `require-literal-id`
+<a id="require-literal-id"></a>
+[See `require-literal-id`](../runtime/docs/reference/lint.md#require-literal-id).
 
-A declaration names itself with a string that is written, not built where the declaration stands. The rule reads
-every declaration of the public vocabulary that names itself — `defineFeature`, `defineApplication`,
-`defineCondition`, `defineHostContract`, `defineModel`, `definePort`, `defineSlot`, `defineSwitchSlot`,
-`definePipe` and `defineRegistry`, and the four of the optional Navigation package: `defineScreen`,
-`defineSurface`, `defineLink` and `defineLinkHandlers`. D280 gives them one form: the id is the first argument of
-every one of them.
+<a id="id-naming"></a>
+[See `id-naming`](../runtime/docs/reference/lint.md#id-naming).
 
-Written means a string literal, a template with no expressions, a name that resolves to an import or to a `const`
-of the same module, and a property read from such a name. Built means anything the call site assembles: a template
-with an expression, a concatenation, a call, or a name that resolves to a parameter.
+<a id="layer-placement"></a>
+[See `layer-placement`](../runtime/docs/reference/lint.md#layer-placement).
 
-A project that generates a set of declarations from a name says so once, by naming that factory:
+<a id="no-snapshot-read-in-render"></a>
+[See `no-snapshot-read-in-render`](../runtime/docs/reference/lint.md#no-snapshot-read-in-render).
 
-```js
-'opetope/require-literal-id': ['error', { allowInCallees: ['createSlots'] }],
-```
+<a id="no-snapshot-in-update"></a>
+[See `no-snapshot-in-update`](../runtime/docs/reference/lint.md#no-snapshot-in-update).
 
-The name is matched against the function the declaration is written in and against the call it is passed to, so
-both shapes of a factory are covered.
+<a id="no-command-in-deps"></a>
+[See `no-command-in-deps`](../runtime/docs/reference/lint.md#no-command-in-deps).
 
-**The boundary.** The rule follows names inside one module only: an id imported from another file is written
-there, and that is where its own text is checked. The kernel's `defineModule`, `defineCallTarget` and
-`defineCallLane` are not read, because an author never writes them.
+<a id="no-subscribe-outside-models"></a>
+[See `no-subscribe-outside-models`](../runtime/docs/reference/lint.md#no-subscribe-outside-models).
 
-### `id-naming`
+<a id="prefer-effect-current"></a>
+[See `prefer-effect-current`](../runtime/docs/reference/lint.md#prefer-effect-current).
 
-An id starts with a letter and joins segments of letters and digits with one of `.`, `/`, `:` or `-`, within 160
-characters. That is the grammar `declarationId` accepts in `@opetope/core`; an id outside it is a `DeclarationError`
-the moment the declaration runs, and this rule says so before the code runs. A screen, a surface and a link handler
-registry pass their id through the same `declarationId`, so this rule reads them too; `defineLink` is left out of it
-because a link id is a canonical lower-case path segment of a URL, which the package checks itself and which no
-reserved prefix applies to (D313).
-
-A project that reserves a first segment names it, and every declaration of those files must open with it:
-
-```js
-'opetope/id-naming': ['error', { prefix: 'workspace' }],
-```
+<a id="no-write-after-source-write"></a>
+[See `no-write-after-source-write`](../runtime/docs/reference/lint.md#no-write-after-source-write).
 
-**The boundary.** The rule checks the ids whose text it can see in the file — a literal, or a name that resolves to
-one in the same module. An id that arrives from another module is checked where it is written.
+<a id="capture-command-cleanup"></a>
+[See `capture-command-cleanup`](../runtime/docs/reference/lint.md#capture-command-cleanup).
 
-### `layer-placement`
+<a id="prefer-model-selection"></a>
+[See `prefer-model-selection`](../runtime/docs/reference/lint.md#prefer-model-selection).
 
-Each declaration is written in the layer that owns it. The rule reports nothing until a project names its layers
-through `configs.layers`, because the names of directories are not a law of the framework:
+<a id="no-retired-vocabulary"></a>
+[See `no-retired-vocabulary`](../runtime/docs/reference/lint.md#no-retired-vocabulary).
 
-| Declaration                                                                                                                              | Layer                                                  |
-| ---------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ |
-| `defineFeature`                                                                                                                          | integration — a feature composes the other two layers  |
-| `defineModel`                                                                                                                            | models, or the UI contracts that declare a mount model |
-| `defineSlot`, `defineSwitchSlot`, `defineSurface`, `definePipe`, `defineRegistry`, `definePort`, `defineCondition`, `defineHostContract` | integration, or the UI contracts beside the component  |
-| `defineApplication`                                                                                                                      | none of them: the host bootstrap owns it               |
+<a id="coexistence-with-key-sorting"></a>
+[See Coexistence with key sorting](../runtime/docs/reference/lint.md#coexistence-with-key-sorting).
 
-**This is a convention of the project, not a law of the library.** The framework says a feature's UI imports only
-that feature's own contracts, and that a model knows nothing about the feature; where those files live is the
-project's choice, and this rule holds whatever choice it declared.
-
-### `no-snapshot-read-in-render`
-
-`getSnapshot()` called while a component or a hook renders reads the value once and never hears the next one. Read
-it with `useReadable`, or select it together with the commands of the same model:
-`useModel(Declaration, (model, { read }) => ...)` (D205, D214).
-
-A render scope is a function named `use…`, or a capitalized function that returns elements. The rule looks at the
-function the call is written in, so a snapshot read in an event handler, an effect or any other nested callback
-stays: those run after render, and the value of that moment is the one they want.
-
-**The boundary.** The rule reads the name of the receiver, not its type: every `getSnapshot()` in a render scope is
-reported, whichever object it belongs to. A capitalized function that returns no element is a factory and keeps its
-reads — including a contribution's model factory, which reads the props of its own mount.
-
-### `no-snapshot-in-update`
-
-A value passed to `update` reads the state it is about to replace — a composite one,
-`update(sessions, { items: sessions.getSnapshot().items, kind: 'loading' })`, and a scalar one,
-`update(total, total.getSnapshot() + amount)`, alike. The read runs where the argument is written — before the
-write, and on a state that may already have stopped, where `getSnapshot()` answers a value nothing will move again
-— and the value it computed then lands on a state that may have moved since. The updater form has neither problem: it reads at write
-time, and a write dropped because its context was aborted never calls the updater at all (D282, D288, D295).
-
-```ts
-update(sessions, previous => ({ ...previous, kind: 'loading' }));
-update(total, previous => previous + amount);
-```
-
-The rule reports a call of `update` — by that name or through a context, `ctx.update` — with exactly two arguments,
-whose first argument names a state and whose value reads `getSnapshot()` on that same state: written into the value
-itself, or through a name of the same function that holds the read — `const current = s.getSnapshot()`,
-`const { items } = s.getSnapshot()`, or a `let` nothing writes again. A `getSnapshot()` of another readable inside
-the value is a read of another state and stays; so do a value that is already an updater, a read written anywhere
-but in that value, and a second argument that is a spread, whose arguments are assembled somewhere else.
-
-The fix writes the updater: the value becomes `previous => ...` with every read of that state replaced by the
-parameter — a destructured field by the field of it, `previous.items` — and the `const` that held the read goes with
-it, comment and all, where this value was its only reader. The parameter is named `previous`, or `snapshot` where an
-enclosing scope already holds `previous`. Where the parameter would shadow a name the file has, where the named read
-has another reader that stays behind, and wherever the read was taken apart or opened with a `let`, the same rewrite
-arrives as a suggestion instead, because those are the rewrites a reader should look at. A value that cannot move
-into a function body at all — one that writes an `await` or a `yield` there, assigns, increments or `delete`s —
-gets the report and nothing else, and so does a read this value keeps for a later call.
-
-**The boundary.** `update(S, ...S.getSnapshot()...)` is specific enough on its own, so the rule resolves no import
-and reads no type: a host's own `update` of the same shape is reported too, and the fix is right for it only if it
-accepts an updater as its second argument. A name is the binding it resolves to, but a member expression is the
-path it spells, so two different objects written `this.state` are one state here. The rewrite moves the whole value
-into a function body, so everything else the value called — `Date.now()`, a helper, a formatter — is computed at
-write time instead of where it was written, and is not computed at all for a write the runtime drops; that is what
-the updater form means, and it is worth reading once before the rewrite lands. A read the value reaches by any other
-route — a helper that takes the state and reads it, a name declared in another function, a name the code writes
-again, a value that is already an updater — is not seen, and silence is not proof that a value computed itself from
-the previous one.
-
-### `no-command-in-deps`
-
-A command hook is a snapshot of the render it was read in: the object is rebuilt on every `inFlight` and `outcome`
-change, while `run` keeps one identity for the life of the binding (D290). A dependency array that names the object
-therefore fires on each of those changes: an effect re-runs, a memo is voided, and an effect that calls `run` from
-it never settles — it starts the command, the status flips, the dependency changes, the cleanup runs, and the
-effect runs again.
-
-```tsx
-const load = useCommand(Screen.load);
-const unload = useCommand(Screen.unload);
-
-useEffect(() => {
-  load.run();
-  return () => void unload.run();
-}, [load.run, unload.run]);
-```
-
-The rule reads the dependency array of `useEffect`, `useLayoutEffect`, `useInsertionEffect`, `useCallback`,
-`useMemo` and `useImperativeHandle`, and reports an element that is a command hook binding taken whole: the
-variable of a `useCommand`, and a key or a destructured name of a `useModel` selection the same code reads `run` on.
-`x.run` and the statuses `x.inFlight` and `x.outcome` are members of that object rather than the object, and they
-stay.
-
-The record itself is the worse shape and carries its own report: `useModel` with a selection builds a new object on
-every render, so `[hooks]` and `[order]` change on every render rather than on every status. The answer is the field
-the callback reads — `hooks.save.run`.
-
-The fix is written where the answer is one: a callback that reaches the binding through a single `run` gets that
-path in place of the element, whatever the element was written past — an `as`, a `satisfies` or a `!` is replaced
-along with it, and an array that already names the path loses the element instead of doubling it. Where the callback
-reads more than one path, or reads a status, the rule offers suggestions instead — one per path, statuses first —
-because which of them the dependency means is the author's to say. A callback this rule cannot read through — one
-written elsewhere, one that keeps the object itself, takes it apart, or reads a member outside those four — gets the
-report and no suggestion at all.
-
-**The boundary.** Names are resolved by import within one module, not by spelling: `useCommand` and `useModel` are
-the imports of `@opetope/react`, the six hooks are React's own, and a local alias of either —
-`import { useEffect as effect }` — is the same import. React is the module named `react` exactly; an `@opetope/*`
-name is also taken from a relative import, which is how a package re-exports its own entry through a barrel, so a
-neighbouring `./scheduling` is React's no more than `@host/scheduling` is. React's hooks are read through a
-namespace or a default binding as well (`React.useEffect`); an `@opetope/*` entry has no default export, and only a
-namespace reaches it. Only a `const` holds the hook it was opened with, so a `let` is left alone. A selected
-`useModel` field is a hook only where the code proves it by reading `run` on it — a status name proves nothing,
-since plain data carries one as easily — and a field read as data is of unknown kind and is left alone, as is
-`useModel(Declaration)` without a selection, which keeps returning the granted model. A dependency array of a call
-that is not one of the six hooks belongs to whoever declared it.
-
-### `no-subscribe-outside-models`
-
-A subscription written by hand owns a cleanup that nothing around it can see. The rule reports `x.subscribe(...)`
-and stays off until `configs.layers` names the model layer that is allowed to hold one; in a component the reader
-is `useReadable` or a model selection, and in a feature or a model it is `effect`, `event` or the `connect` of
-`resource.live`.
-
-Handing the function over without calling it is not a subscription written here:
-`useSyncExternalStore(source.subscribe, source.getSnapshot)` passes a reference, and the reader owns what it starts.
-
-Neither is a subscription written where a declared node opens its work and owns the release of it. The disposer
-such a callback returns belongs to that node and is drained with the generation that opened it, so the rule stays
-silent there — this is the shape its own message asks for (D299):
-
-| Callback                                | Where                       | Ingress |
-| --------------------------------------- | --------------------------- | ------- |
-| `resource.live({ connect })`            | the `connect` member        | yes     |
-| `event(source, subscribe, run)`         | second argument             | yes     |
-| `scope.while` / `scope.switch`          | `open`, second argument     | yes     |
-| `scope.each(source, key, open)`         | `open`, third argument      | yes     |
-| `attach(source, { open })`              | the `open` member           | yes     |
-| `attach(source, { open, close })`       | the `close` member          | no      |
-| `apply`, `load`, `run`, `filter`, `key` | modifiers of the same calls | no      |
-
-`resource.load` opens no subscription and has no ingress at all, so a `subscribe` written in its `load` is reported
-like any other hand-written one (D349).
-
-<!--example
-import { defineFeature, defineHostContract } from '@opetope/runtime';
-
-type Exchange = Readonly<{
-  repository: Readonly<{ subscribe(pair: string, emit: (quote: Quote) => boolean, signal: AbortSignal): () => void }>;
-}>;
-
-const exchangeContract = defineHostContract<Exchange>('example.exchange.platform');
-const bookFeature = defineFeature('example.book', {
-  imports: { exchange: exchangeContract },
-/* … */
-});
--->
-
-```ts
-own: ({ imports, resource }) => ({
-  book: resource.live({
-    apply: { change: (_current: ResourceData<Quote>, change: Quote) => change },
-    connect: ({ emit, signal, source }) => source.repository.subscribe('BTCUSD', emit, signal),
-    lifetime: 'owner',
-    source: imports.exchange,
-  }),
-}),
-```
-
-Inside counts all the way down — a nested arrow, a `function` body, an `await` on the subscription itself, a
-disposer named before it is returned. The context is resolved by import, not by spelling: the `own` section written
-right where a `defineFeature`/`defineFeature.body` **taken from `@opetope/runtime` itself** receives it, and a model
-factory — the second argument of `model(Declaration, factory)` on that same `own`, or a function whose first
-parameter is annotated `ModelContext` from `@opetope/core`. Unlike `no-command-in-deps`, these two anchors take the
-package name and nothing else: a relative import here would let a host's own `./my-own-context` silence the rule.
-`own.resource.live(...)` and a destructured `resource.live(...)` read alike, an alias answers with the key it was
-taken from (`{ resource: materialize }` is still `resource`), and `own.scope.while(...)` reads like the destructured
-`scope.while(...)`.
-
-Four shapes therefore keep the report, and each is a limit of what syntax proves: a `resource.live` traced to none of
-those anchors (imported from elsewhere, unresolvable, or belonging to another `defineFeature`); a callback written
-elsewhere and passed in by name, which is not lexically inside; an `own` section hoisted to its own binding
-(`const own = ({ resource }) => …; defineFeature(id, { own })`); and `model(Decl, createOrderModel)` where the factory
-is a named function without the `ModelContext` annotation.
-
-### `prefer-effect-current`
-
-The `run` of an effect is already given the value it was started for — as its first parameter, since D379. Reading
-the same source through `source.getSnapshot()` inside that run reads it a second time and says nothing about which
-run this is, so the rule rewrites it to that parameter (D296, D323, D379):
-
-```js
-// before
-ctx.effect(quotes, current => publish(quotes.getSnapshot()));
-// after
-ctx.effect(quotes, current => publish(current));
-```
-
-The fix writes the word the run already has: the name the author bound the first parameter under, whatever it is. A
-run that destructured the value itself, or took no parameter at all, has no word for the whole of it, so the report
-stands alone.
-
-**The two cases it reports without rewriting.** Past the first `await` of the run, the parameter is the value this
-run started with and the snapshot is the value of the moment; a change of the source normally restarts the run, so
-the two normally agree — and «normally» is not a licence to rewrite. Under `filter` they legitimately differ: the
-predicate admits some values and skips others, so the source moves without restarting the run (D168, D296, D379). A
-modifier record this rule cannot read — one assembled elsewhere — is treated as if it carried the predicate.
-
-A read inside a nested callback of the run — a `timers.delay`, a subscription handler — is left alone: that code
-runs later than the run does, and the value of that moment is the one it wants. Like every rule that rewrites code,
-this one resolves its context exactly: the `effect` it acts on is the one declared on a `ModelContext` parameter or
-on the context of a `model(Declaration, factory)` written inside a `defineFeature` of `@opetope/runtime` (D309).
-
-### `no-write-after-source-write`
-
-A write of an effect run into a cell its own source reads changes the value that source publishes, and the
-notification is synchronous: the run is aborted inside that write, so every write of the run after it is dropped and
-an `invoke` after it is refused. The first of those dropped writes reaches the reporter as `LostWrite`, once per run
-and saying the rest went with it (D432); the refused `invoke` is still silent, and so is every other way a write is
-lost. The rule reports the write that moves the source when another write of the same run can follow it
-(spec §2.11, D288, D365, D432, D447):
-
-```ts
-// reported: the deposit is never written down, because releasing the key ended the run
-const key = context.state<string | null>('idempotency-1');
-const deposit = context.state<string | null>(null);
-const source = derive([frames, key], (frame, held) => `${frame}:${String(held)}`);
-
-context.effect(source, (_current, { update }) => {
-  update(key, null);
-  update(deposit, 'deposit-1');
-});
-```
-
-A command the run `invoke`s writes under the same authority. `invoke` hands the command the cancellation of the run,
-so one abort ends them both, and a write of that command into a cell the run's source reads ends the run exactly as
-the run's own write does. A write the run reaches after that is dropped and recorded as `LostWrite` like any other
-(D447) — but the run is usually _awaiting_ that call when the abort lands, and then the promise it awaits is
-cancelled and the body reaches no write at all. Nothing is dropped there for the runtime to record, so this rule is
-the only finder of that shape, and it reports the call where it is written:
-
-```ts
-// reported: the write that releases the key is the command's, and the deposit below the call is never reached
-const key = context.state<string | null>('idempotency-1');
-const deposit = context.state<string | null>(null);
-const source = derive([frames, key], (frame, held) => `${frame}:${String(held)}`);
-const release = context.command(({ update }: ModelCommandContext<void>) => {
-  update(key, null);
-});
-
-context.effect(source, async (_current, { invoke, update }) => {
-  await invoke(release);
-  update(deposit, 'deposit-1');
-});
-```
-
-Whether the drop shows in the data is a second question, and it is why such a defect used to be found in production
-rather than in a test: the loop opens a successor run for the new value where `filter` admits it, and a successor
-that repeats the write hides the loss — the cell ends up correct through the second run. The loss stands whole where
-the successor does not repeat that write, which is what a guard does (`if (held === null) return`), and where no
-successor opens at all, which is what a `filter` that rejects the new value does (D329). The record arrives in every
-one of those shapes, the hidden one included: it speaks about the write that was dropped, not about the value the
-cell ended up with (D432).
-
-There is no fix: which of the two writes the author meant to keep is the author's to say, and the message names three
-ways out — make the write into the source the run's last write, or keep what the run accumulates out of its source and
-read it with `getSnapshot()`, which also saves the second run, or take `execution.capture(state)` before the moving
-write, which is the one that saves this write whole although it saves nothing written after it. It names them in the
-words the `LostWrite` record prints, and `ci:source` holds the two texts equal, because the author reads the rule
-before any run reports (D319, D432, D442, D447).
-
-**What it proves before it reports.** Three things, and a fourth where the moving write is a command's; it says
-nothing where it cannot prove one of them.
-
-_The declaration._ The `effect` is declared on a context of this library — the `effect` of a `ModelContext`
-parameter, or of the context of `model(Declaration, factory)` written inside a `defineFeature` of `@opetope/runtime`
-(D309). The run is the function the declaration takes, written there or bound to a name in this module.
-
-_The cell is part of the source._ Either the source is that cell, or it is a `derive` of `@opetope/core` — written
-where the declaration takes it, or held by a name in this scope — whose dependencies name the cell, and whose
-selector publishes the value of that dependency. That last clause is the carve-out of the law itself: a write that
-leaves the published value equal ends nothing, so a selector that only asks a question about its dependency —
-`held === null ? 'none' : 'some'`, `!held`, `typeof held`, `held ? a : b` — publishes the same word for one key as
-for another, and the rule stays silent over it. So does a selector that drops the dependency, and a selector this
-file cannot read.
-
-_The write can run after it._ The writes are the writer of this run, read under the same names as
-`capture-command-cleanup` reads a command's: `execution.update(…)`, `({ update })` or `({ update: write })` in the
-parameter list, and `const { update } = execution` in the body. The later write has to stand in the same block, in a
-later statement, with no unconditional exit of the run between the two: `if (held === null) { update(key, null);
-return; }` has a write below the `if` that cannot run after this one, and it is not reported. A `break` or a
-`continue` is not such an exit, because the code below it runs.
-
-_The command makes that write._ Where the moving write is a call rather than a write, the call is an `invoke` of the
-run, read under the same names as the writer, and its first argument is a name this module holds a
-`context.command(body)` in — declared on the context of a model, because the `command` of a feature's `own` takes its
-body second and is handed no writer (D385, D386). The body is the function that declaration takes, written there or
-bound to a name in this module, and at least one write through the context of that body names a cell of this source.
-A later write of the run has to follow the call by the same rule as it follows a write.
-
-**The boundary.** Silence is not proof that a write lands. Beyond the shapes above, the rule does not read: a
-source assembled in another function, a source read off an object (`deps.sources`, the shape of the latch recipe), a
-cell that arrived as a parameter, a `derive` over a `derive`, and a writer held by a closure. It reads only `update`
-as the moving write, so a commit into the source — the same law, `update` or commit alike — is not reported; neither
-is the third form of that loss, a `capture` taken _after_ the moving write, which throws the run's own cancellation
-and is reported nowhere. Two writes of one statement are not a sequence — the branches of an `if`, the arms of a
-ternary, the halves of a `try`, the sides of a comma — and neither are two writes of one `switch` case. A write in a
-nested callback of the run is left alone, because the run is already over when a timer or a disposer runs and its
-dropped write has its own reason. A loop whose write into the source goes last loses the first write of the next turn,
-and the rule misses that one.
-
-The call has a boundary of its own, and it is the boundary of one step. A command that arrived as a dependency
-(`invoke(deps.release)`), one whose declaration is in another module, one declared on a context this file cannot
-resolve, and one whose body is assembled elsewhere name nothing this rule can read. It reads one step only: a command
-that moves the source through a second command it invokes, or through a `capture` of a cell of the source, is not
-reported, and neither is a command whose body writes the source through a writer it took from somewhere other than
-its own context. And the `invoke` of a run whose loss is the call itself — a run with no write after that call —
-is not reported either, because nothing there is lost: the `await` does not return, and the run had nothing left to
-do (D447).
-
-### `capture-command-cleanup`
-
-The writer of a command lives as long as its caller (D288). A write in the `finally` or the `catch` of a `try` that
-awaits runs after the `await`, and once the call is cancelled it is dropped without a record — so the cleanup that
-was supposed to clear a busy flag or a pending mark is exactly the write that never lands. The rule reports that write
-and names the word that does land, a commit taken before the `await` (D319, D330):
-
-```ts
-// reported: once the caller is cancelled, `busy` stays `true`
-ctx.command(async ({ input, signal, update }: ModelCommandContext<Payload>) => {
-  update(busy, true);
-  try {
-    await host.send(input, signal);
-  } finally {
-    update(busy, false);
-  }
-});
-
-// the cleanup lands while the model lives
-ctx.command(async ({ capture, input, signal, update }: ModelCommandContext<Payload>) => {
-  update(busy, true);
-  const done = capture(busy);
-  try {
-    await host.send(input, signal);
-  } finally {
-    done.update(() => false);
-  }
-});
-```
-
-There is no fix: whether a cleanup must land after its caller left is the author's decision, and the drop is the law
-for a reason — a late write of a cancelled call must not overwrite what a newer call wrote. The report therefore names
-both ways out. A cleanup that must run for a cancelled call goes through `capture(state)` taken before the `await`; an
-answer that must not land after cancellation — a failure, a result — belongs in a `catch` after
-`rethrowIfCancelled(cause)`. Where a caller cancels one run to start the next — a search its consumer issues again, a
-Command an effect run invokes and a newer value cancels — the older run's write is exactly the one that should not land,
-and a disable comment says so.
-
-Under `concurrency: 'parallel'` the report does not advise a commit. Runs of such a command overlap, so a cancelled
-call's captured cleanup would clear a flag another call still holds — a flag shared by parallel calls is racy either
-way — and the report says to keep that state per call, or to leave progress to the consumer's `inFlight`. The rule
-sees the order only when `{ concurrency: 'parallel' }` is written on the `command` itself; a modifier record assembled
-elsewhere reads as the default queue, where the lane waits for the physical body and a captured cleanup lands in
-order (D387).
-
-The rule is a heuristic over syntax, and it proves nothing about a write it does not report. It reads the writer of a
-command body under these names: `execution.update(…)`; `({ update })` or `({ update: write })` in the parameter list;
-`const { update } = execution` inside the body; and a `const` that gives one of those a second name —
-`const write = update` or `const write = execution.update`. It follows a body passed as a local function. It misses a
-closure that holds the writer (`const clear = () => update(busy, false)` called in `finally`), a writer stored anywhere
-but a `const`, and a context handed to a helper. A `try` counts when its protected block awaits in the body's own
-function: an `await` or a `for await` inside a nested callback suspends that callback, not the command.
-
-In a `catch`, a write that follows `rethrowIfCancelled(cause)`, `signal.throwIfAborted()` or an `if (signal.aborted)`
-that throws or returns — in the block that holds the write or in any block around it — is not reported. Such a guard
-is the author's statement that what follows must not run for a cancelled call, and the rule takes it at its word: in
-`catch (cause) { rethrowIfCancelled(cause); update(busy, false); throw cause }` the flag stays `true` on cancellation
-and nothing is reported. A flag that must clear on cancellation is therefore written in `finally` through
-`capture(state)`. A guard in a `finally` saves nothing and is still reported, and so is a check of `signal.aborted`
-that neither throws nor returns. `effect`, `event` and the other reactions are left alone: a newer value is what
-cancelled their run, and dropping its write is the point (D288). The context is resolved exactly: the `command` of a
-`ModelContext` parameter or of the context of `model(Declaration, factory)` inside a `defineFeature` of
-`@opetope/runtime` (D309); a feature's own `command` hands its body no writer.
-
-### `prefer-model-selection`
-
-A component that takes one granted model and reads its fields through a hook each repeats the same wiring. From
-three fields upwards the rule points at one selection instead (D205, D214):
-
-```js
-'opetope/prefer-model-selection': ['error', { threshold: 3 }],
-```
-
-It counts `useReadable(model.field)` and `useCommand(model.field)` over the variable of a `useModel(Declaration)`
-without a selection, and it counts each granted model separately: two models in one component are two grants, and
-the same variable name in two components is two counts. There is no fix — the shape of the selection is the
-author's to write.
-
-### `no-retired-vocabulary`
-
-The words the D365–D411 wave retired, each named together with the word that replaced it. The rule is written for
-one migration pass: this release ships no alias for any of them, so a source that still writes one has not been
-migrated, and once it has been the rule never fires again.
-
-| Retired                                                                                                             | Is now                                                      | Decision |
-| ------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- | -------- |
-| `invalidate()` of a Resource                                                                                        | `reset()`                                                   | D373     |
-| `backpressure` of an event                                                                                          | `delivery`                                                  | D374     |
-| `kind` inside a delivery record                                                                                     | `pending`                                                   | D374     |
-| `key` inside a delivery record                                                                                      | `by`                                                        | D374     |
-| `activity` of a `loading` state                                                                                     | `failure`                                                   | D375     |
-| `scope.keyed(source, open, { key })`                                                                                | `scope.each(source, key, open)`                             | D378     |
-| `skipInitial`                                                                                                       | `initial`, with the polarity inverted                       | D379     |
-| `when` of an effect                                                                                                 | `filter` **or** `initial`                                   | D379     |
-| `onDispose`                                                                                                         | `finalize`                                                  | D379     |
-| `externalReadable`                                                                                                  | `fromExternal`                                              | D380     |
-| `Call`, `ctx.call`, `runCall`                                                                                       | `Command`, `ctx.command`, `runCommand`                      | D385     |
-| `policy`, `queueBy`, `lane`                                                                                         | `concurrency`                                               | D387     |
-| `ctx.calls`, `own.calls`, `useCommands`                                                                             | `ctx.select`, `own.select`, `useModel(Declaration, select)` | D388     |
-| `once`                                                                                                              | `memoize`                                                   | D389     |
-| `from` of `defineCondition`                                                                                         | `source`                                                    | D411     |
-| `when` of a contribution                                                                                            | `enabled`                                                   | D411     |
-| `overflow: 'reject'` of a live Resource                                                                             | `overflow: 'drop'`                                          | D411     |
-| `status` of a `CommandOutcome`                                                                                      | `kind`                                                      | D411     |
-| `ResourceActivity` of `@opetope/devtools`                                                                           | `ResourceNodeActivity`                                      | D411     |
-| `ResourceDisposer`                                                                                                  | `Disposer`                                                  | D411     |
-| `NavigatorPolicy`, `surface.policy`                                                                                 | `NavigatorCatalogue`, `surface.catalogue`                   | D411     |
-| `ApplicationConditionBinding`, `ApplicationExecution` and `ApplicationImportBinding` of `@opetope/runtime/internal` | the same names, from `@opetope/runtime`                     | D411     |
-
-**One row cannot be executed from the word alone, and the report says the rest of it.** `ctx.call` becomes
-`ctx.command`, and with it a body of `(input, context) => …` becomes a body that takes its context alone — which
-leaves the input with nowhere to be named, because TypeScript has no partial inference and `command<Deposit>(…)` is
-not a route. The one place is the annotation of the destructured context,
-`({ input, update }: ModelCommandContext<Deposit>)` in a model and
-`({ input, source }: FeatureCommandContext<typeof within, Deposit>)` in a feature, so the report names that
-annotation beside the word. A rename carried out to the letter without it leaves this rule silent and the build red,
-with every refusal standing on code the author wrote correctly (D444).
-
-**There is no autofix, and that is the decision rather than an omission (D404).** Several of these rows are not one
-to one. `policy`, `queueBy` and `lane` collapse into a single `concurrency` whose shape depends on which of the
-three a record wrote together: `{ by }`, `{ by, lane }` and `{ lane, pending: 'latest' }` are three different values
-built from the same three words. `when` at an effect becomes `filter` **or** `initial`, and which one is a question
-about what the predicate asks — `filter: (_current, previous) => previous !== undefined` is not a filter at all, it
-is `initial: false`, and the authoring guide says so. `skipInitial` becomes `initial` with the polarity inverted, so
-the one row that looks purely mechanical is the one that compiles and means the opposite. A fix that guessed wrong
-would rewrite a consumer's source silently, which is worse than refusing, so every report here names the retired
-word, names its replacement, and says outright where the replacement is a choice.
-
-**The boundary.** Ownership is proved by symbol and never by spelling. A retired member is reported only on a
-declaring context of this library — a parameter annotated `ModelContext` of `@opetope/core`, or the `own` section
-written where a `defineFeature` of `@opetope/runtime` takes it — resolved through an alias or a destructured member
-the same way `no-subscribe-outside-models` resolves the ingress of a declared node. A retired name is reported only
-where an `@opetope/*` module is the one that exports it, and where the name is retired at one entry and live at
-another the module is asked exactly: `ResourceActivity` is still what `@opetope/core` calls the background work of
-a `ready` state, and the three names of `@opetope/runtime/internal` are still names on the entry an author takes
-them from. A
-contribution's gate is reported on the `provides` section a `defineFeature` of `@opetope/runtime` takes, the way a
-declared node is reported on `own`; the `status` of a settled answer only on the `outcome` of a `useCommand` of
-`@opetope/react`, and the `policy` of a surface only on the value a `defineSurface` of `@opetope/navigation/react`
-declared. A Resource is the value a `resource.load` or
-`resource.live` of such a context declared, or the record `useResource` of `@opetope/react` answers; its state is
-that record's `state`, or a `getSnapshot()` of it. `activity` is reported only inside a
-narrowing that proves the state is `loading` — an `if`, a ternary or the left half of an `&&`, written about the
-same expression — because a `ready` state still carries the field.
-
-The silence is the point. `Call` inside `'Margin Call'` and inside the translation keys of a catalogue, the
-`{ once: true }` of `addEventListener`, a host's own `policy` option or `policy` of somebody else's object, `Navigator.reset()` and a
-`delivery` field of
-somebody else's record are all left alone, as is `when` at a feature and at `scope.while`, where the word is not
-retired at all, and a `status` of somebody else's record. So is what the rule cannot see: a Resource reached through a model record instead
-of through the declaration that built it, a state narrowed in a `switch` or inside a helper, and an options record
-assembled in another module. Its silence is therefore not proof that a migration is complete — the compiler, which
-now prints the replacement for every word it can name, is the other half (D401, D444). Six of the rows above are
-words an options record used to carry, and each of those records names its retired word so the refusal carries the
-replacement: `skipInitial`, `when` and `onDispose` at an effect, `backpressure` at an event, `when` at a
-contribution and `from` at `defineCondition`.
-
-## Coexistence with key sorting
-
-A host that sorts object keys alphabetically will disagree with `define-feature-property-order`, because the
-sections of a feature are ordered by meaning and not by name. `recommended` touches no sorting rule: reconciling
-them belongs to the host, and there are two ways.
-
-**`perfectionist/sort-objects`** takes a named order for exactly the two callees that declare sections, and keeps
-its plain configuration for every other object:
-
-```js
-'perfectionist/sort-objects': [
-  'error',
-  {
-    customGroups: [
-      { elementNamePattern: '^id$', groupName: 'feature-id' },
-      { elementNamePattern: '^imports$', groupName: 'feature-imports' },
-      { elementNamePattern: '^requires$', groupName: 'feature-requires' },
-      { elementNamePattern: '^own$', groupName: 'feature-own' },
-      { elementNamePattern: '^exports$', groupName: 'feature-exports' },
-      { elementNamePattern: '^provides$', groupName: 'feature-provides' },
-      { elementNamePattern: '^when$', groupName: 'feature-when' },
-      { elementNamePattern: '^body$', groupName: 'feature-body' },
-    ],
-    groups: [
-      'feature-id',
-      'feature-imports',
-      'feature-requires',
-      'feature-own',
-      'feature-exports',
-      'feature-provides',
-      'feature-when',
-      'feature-body',
-      'unknown',
-    ],
-    order: 'asc',
-    type: 'natural',
-    useConfigurationIf: { callingFunctionNamePattern: '^(?:defineFeature|defineFeature\\.body)$' },
-  },
-  { order: 'asc', type: 'natural' },
-],
-```
-
-**ESLint core `sort-keys`, and the rule of the same id in Oxlint**, has no per-callee configuration and no
-per-declaration exception: it reports each key that follows a larger one, wherever the object is. Turn it off for
-the files that declare features, or wrap a declaration in `/* eslint-disable sort-keys */` and
-`/* eslint-enable sort-keys */` — a `// eslint-disable-next-line sort-keys` covers one line, so it silences one
-section, not a multi-line declaration. Oxlint reads the same directives under its own prefix,
-`// oxlint-disable-next-line sort-keys`.
-
-The fix of this rule moves keys only inside the object of a `defineFeature` call, so it never reorders anything a
-sorting rule owns elsewhere in the file.
-
-## Running the rules under Oxlint
-
-Oxlint reads ESLint plugins through `jsPlugins`: it imports the module by path and takes its default export. The
-rules stay on the plain rule API — `meta`, `create(context)` with visitors, `context.report` with a `fix`, and
-`getText`/`getCommentsInside` on the source code — with no typed services and no ESLint-only capability, so both
-linters run them, autofix included:
-
-```json
-{
-  "extends": ["./node_modules/@opetope/lint/oxlintrc.json"],
-  "jsPlugins": [{ "name": "opetope", "specifier": "./node_modules/@opetope/lint/dist/index.js" }]
-}
-```
+<a id="running-the-rules-under-oxlint"></a>
+[See Running the rules under Oxlint](../runtime/docs/reference/lint.md#running-the-rules-under-oxlint).
 
-Those are the two lines, and neither of them is a transcription. `@opetope/lint/oxlintrc.json` is generated from
-`configs.recommended.rules` and shipped in the package, so a rule the package adds arrives with the upgrade instead
-of being missed by a hand-written severity map. `extends` in `.oxlintrc.json` takes a **file path**, resolved
-relative to the config that names it — not a package specifier — which is why the fragment sits at the root of the
-package and the path a host writes is the same string as its export name. Configurations merge first to last, so a
-rule the project wants stricter goes in its own `rules` after `extends`: the three `off` entries above are exactly
-the ones a project turns on by its own directories.
-
-The fragment carries rules and nothing else. Oxlint does merge a `jsPlugins` entry through `extends`, but a host
-that declares the plugin itself — under a wrapper package, as an isolated peer install needs — would then register
-the name `opetope` twice, and the second registration fails the whole configuration. Where the plugin comes from is
-the host's deployment; the severities are this package's contract.
-
-The alias `name` fixes the namespace, so a rule keeps the same id under either linter. `jsPlugins` is alpha and
-outside semver: `npm run ci:test` runs the built plugin under Oxlint on a valid and an invalid fixture, through a
-config that extends the shipped fragment, and checks the fix it writes, so a break in that bridge fails here
-instead of in a host.
-
-`--fix-suggestions` applies the first suggestion of a report without asking, so a suggestion here is only ever a
-rewrite the reported code already justifies. `no-command-in-deps` offers the paths the callback itself reads, the
-status it watches before the `run` it calls; where it cannot read the use through — the object passed on, taken
-apart, or read past the members the rule knows — it reports and offers nothing, and the dependency stays as written
-until its author changes it.
-
-`no-snapshot-in-update` holds the same line from the other side: its suggestion is the fix it would not write
-unasked — a parameter that shadows a name the file already has, or a named read that stays behind for its other
-reader — and both rewrites leave the code doing what it did. Where the value cannot become the body of an updater
-at all, there is no rewrite to offer and the report stands alone.
-
-## Checks
-
-From this package: `npm run ci:test`, `npm run ci:type`, `npm run ci:eslint`, `npm run build`. The Oxlint bridge
-test reads `dist`, so `npm run build` comes first. `ci:test` also checks that the committed `oxlintrc.json` still
-equals `configs.recommended.rules`; after changing that config run `npm run oxlintrc:generate` and commit the
-result, which is why the build never writes it.
+<a id="checks"></a>
+[See contributor checks](../runtime/docs/maintainers/contributing.md).