@stonyx/orm 0.3.2-beta.153 → 0.3.2-beta.155

package/README.md

@@ -381,6 +381,174 @@ export default class GlobalAccess {
 }
 ```
 
+
+### The access context (second argument)
+
+`access()` is called with **two** arguments:
+
+```js
+access(request, { model, operation })
+```
+
+The second is the **access context** — the structural facts about the request,
+which the framework already holds at authorization time. Read these instead of
+parsing anything.
+
+| Key | Value |
+|---|---|
+| `model` | The model this route was mounted for, as a **model name**: kebab-case, exactly as declared under `config.orm.paths.model` and keyed in the store — `'owner'`, `'animal'`, `'phone-number'`. **Not** the pluralized, dasherized, mount-prefixed *route* name. |
+| `operation` | One of **`'read'`, `'create'`, `'update'`, `'delete'`** — and no second vocabulary *on this path*. Never an HTTP method name like `'GET'`, and **not** the hook vocabulary either (see [below](#operation-is-not-the-hook-operation)). `undefined` when the dispatched method has no entry in the framework's method map. |
+
+So a predicate can be written without reference to any URL:
+
+```js
+export default class OwnerAccess {
+  models = ['owner'];
+
+  access(request, { model, operation }) {
+    if (model === 'owner' && operation === 'read') {
+      return record => record.id !== 'angela';
+    }
+
+    return ['read'];
+  }
+}
+```
+
+There is no string to parse, no variant to miss, and no way to fail open through
+a URL shape nobody anticipated. `model` is fixed at mount time and no request
+can influence it — not a mount prefix, not a query string, not a case-varied
+path, not an absolute-form request target.
+
+#### What the context does not tell you: which surface
+
+It names **which model and which verb**, not **which route**. Measured over the
+live router, six surfaces produce one identical context:
+
+```
+GET /owners                          { model: 'owner', operation: 'read' }
+GET /owners/gina                     { model: 'owner', operation: 'read' }
+GET /owners/gina/pets                { model: 'owner', operation: 'read' }
+GET /owners/gina/relationships/pets  { model: 'owner', operation: 'read' }
+GET /owners/archived                 { model: 'owner', operation: 'read' }
+GET /owners/gina?include=pets        { model: 'owner', operation: 'read' }
+```
+
+So a rule that depends on the **sub-path** still needs `request.path` —
+mount-relative and query-free, and the one read of argument one that
+[Identifying the collection](#identifying-the-collection) sanctions. The sample
+access class shipped with this repo has such a rule: its `/archived` deny
+**cannot be expressed from the context alone**, and a predicate migrated to
+context-only would silently drop it — a deny becoming an allow.
+
+Note also that the related-resource and `?include=` surfaces serve *another
+model's* records under `model: 'owner'`, and the context gives a predicate no
+signal that it is authorizing a related-resource route. That is
+[#196](https://github.com/abofs/stonyx-orm/issues/196).
+
+#### `operation` is not the hook `operation`
+
+This module exposes a **second** `operation` vocabulary, on an identically-named
+key of an identically-shaped context object:
+[hook contexts](#hook-context-object) carry `list` / `get` / `create` /
+`update` / `delete`. The access vocabulary collapses `list` and `get` into
+`'read'`, so for one `GET /animals/1` a hook sees `'get'` while `access()` sees
+`'read'` — and a predicate cannot distinguish a collection read from a
+record read.
+
+"No second vocabulary" above is a statement about the **access path**, where
+both the context and the permission array come from one method map. It is not a
+statement about the module. Writing `operation === 'get'` in a predicate never
+matches, and a predicate that stops matching falls through to the permission
+array — so the misreading is fail-open shaped. In TypeScript the exported
+`AccessOperation` union makes it a compile error.
+
+The four `operation` values are the same four strings the permission-array
+return shape is written in (`['read', 'create', 'update', 'delete']`), because
+both come from one method map inside the framework. The two forms cannot
+disagree about the same request.
+
+**`operation` is `undefined`, never defaulted, for an unmapped method.** Express
+delivers `HEAD` to the `GET` handler, so this is reachable. It is deliberately
+not defaulted to `'read'`: a fabricated operation would turn an unclassified
+request into an authorized one. Treat `undefined` as *not classified* and deny.
+
+**The second argument is additive.** JavaScript ignores extra arguments, so an
+existing `access(request)` predicate keeps working exactly as it did. Nothing
+needs to be migrated to keep running — but note that argument **one** is still
+the raw request, so the warning in
+[Identifying the collection](#identifying-the-collection) still applies to any
+predicate that reads it.
+
+#### `record` is not in the context
+
+Deliberately, and it is not an oversight. `auth()` runs after route matching but
+**before any handler executes**, so nothing has been fetched yet. Supplying a
+record would force a pre-fetch on every request — a second store hit, a new
+failure mode, and an ordering change in the middle of an authorization path.
+
+It is also unnecessary: the **function** return shape already *is* the
+per-record hook. Return `(record) => boolean` and the handlers apply it to every
+record the request touches. Auth-time and record-time are separate decision
+points, and the contract keeps them separate.
+
+#### Reaching another model's predicate
+
+The model → predicate map is published on the ORM instance at boot, before any
+route is mounted, so a predicate can be resolved by model name and asked about a
+request routed to a *different* model:
+
+```js
+import Orm from '@stonyx/orm';
+
+const predicate = Orm.instance.getAccess('animal');
+if (!predicate) return deny;
+
+const verdict = predicate(request, { model: 'animal', operation: 'read' });
+```
+
+**`undefined` means no predicate could be resolved — not that the model is
+unrestricted. Treat it as deny.** It covers a model with no access class *and* a
+model whose access class failed to **load**: a load failure is caught and warned
+about, and the partial map is published anyway, so a missing key is not evidence
+of an unrestricted model. This is the same rule as `operation === undefined`
+above, and for the same reason.
+
+The raw map is `Orm.instance.accessFunctions`, keyed by model name; prefer
+`getAccess()` — it is guarded against inherited `Object.prototype` members and a
+direct index is not. Note that it maps a model name to the predicate of the
+access *class* that claims it, which may claim many models: against this repo's
+sample, `getAccess('owner') === getAccess('animal')`.
+
+#### Passing the context makes a model-correct answer *possible*
+
+It does not make the answer model-correct on its own. **The resolved predicate
+has to read the context.** Measured against the access class shipped with this
+repo, on a request Express dispatched to `GET /owners/angela`, asked about
+**animals**:
+
+```
+getAccess('animal')(ownersRequest, { model: 'animal', operation: 'read' })
+  ->  record => record.id !== 'angela' && record.id !== 'restricted'
+```
+
+That is the **owners** filter, and it returns `true` for animal 21 — the record
+hidden on every animal surface. Under a mount that predicate recognizes neither
+way it is worse still: it falls through to
+`['read', 'create', 'update', 'delete']`, a full CRUD grant.
+
+Either way the context was supplied and the answer is not the animal answer, and
+it is wrong in the direction that **grants**. That predicate is single-argument
+and identifies its collection from the request, so it answered about the
+collection the request is *addressed to* while being asked about another one.
+Every predicate in this repo, and in every consumer tree, is single-argument on
+the day this ships, and a caller has no supported way to tell which kind it
+resolved. The boot-time arity warning that would surface it is
+[#213](https://github.com/abofs/stonyx-orm/issues/213).
+
+So: pass the context, and do not treat a resolved predicate's answer as
+model-specific until that predicate has been migrated to read it.
+
 ### Return values
 
 | `access()` returns | Effect |
@@ -413,7 +581,7 @@ a write to a *different* collection can still re-parent one. See
 | `GET /:models/:id/relationships/{relationship}` | `404` — same |
 | `PATCH /:models/:id` | `404`, no attribute is applied |
 | `DELETE /:models/:id` | `404`, the record is not removed and no SQL `DELETE` is issued |
-| `POST /:models` | `403`, and a record **this request inserted** is rolled back — see [Known limitations](#known-limitations) for the case where it did not insert one |
+| `POST /:models` | `403`, and a record **this request inserted** is rolled back — see [Known limitations](#known-limitations) for why the rollback is conditional |
 
 **Denied record-level requests return 404, not 403.** This is deliberate and it
 is the property most easily "improved" away. 403 would confirm that the record
@@ -447,9 +615,64 @@ chooses the id and learns whether the create succeeded — so under a filter the
 caller does not choose the id. The refusal happens before any store lookup, so
 neither the status nor the response time depends on whether the id exists.
 
-Let the server assign the id and read it back from the response. Callers with no
-function-style filter are unaffected: `409` on a duplicate id and `200` on a free
-one both behave exactly as before.
+Let the server assign the id and read it back from the response — and read it
+back rather than predicting it, because the value it returns is documented but
+not stable across model kinds: a numeric-id model gets `max + 1` (or, at the
+numeric ceiling, the lowest free integer), and a string-id model gets
+`<model>-<n>`. See breaking change 8.
+
+**What a server-assigned id is not.** It is not a secret. On a string-id
+collection it is dense and enumerable from `1`, where previously it inherited
+whatever entropy the last-inserted id happened to carry — a UUID-seeded store
+answered a UUID-derived key. If a collection has **no** `access` config its
+record-level routes are ungated, so the id was the only thing standing between
+an unauthenticated caller and `GET`/`PATCH`/`DELETE` on a record. That was never
+a control and must not become one; configure `access`.
+
+**And the id itself is an occupancy signal — on both model kinds.**
+`assignRecordId` reads the whole store, not the caller's filtered view — it
+never sees `state.filter` — so the id it returns is a function of records the
+caller may not be permitted to read. **This applies to numeric-id collections
+as well as string-id ones**, and the conditions differ, so read both:
+
+- **String-id collections, always.** The assigned `n` is the smallest positive
+  integer whose landing key is free, which tells the caller that every key
+  below it is taken, hidden or not.
+- **Numeric-id collections, once one record sits at the numeric ceiling.** The
+  normal answer is `max + 1`, which discloses only the maximum. But `max + 1`
+  is not representable at or above 2^53, so the walk restarts from `1` (see
+  breaking change 8) and the assigned id becomes the smallest free integer —
+  the same occupancy predicate, now over arbitrary low keys. Each subsequent
+  no-id `POST` names the next free one, so a caller can enumerate the holes in
+  a range it cannot read.
+
+**A ceiling record reaches a filter-protected collection even though `POST`
+refuses caller ids on one.** Breaking change 3 makes
+`POST /animals {"id": 9007199254740992}` answer `403`, but the same id lands
+through a *relationship write on another collection* —
+`POST /owners` carrying `attributes: { pets: [{ "id": 9007199254740992 }] }`
+creates the animal under that key
+([#207](https://github.com/abofs/stonyx-orm/issues/207), the same channel the
+**Known limitations** re-parenting note describes). So the precondition is
+reachable by an unauthenticated caller on exactly the collections `access`
+exists to protect. Measured on the sample fixture, with every animal hidden by
+the `/animals` predicate and keys 4 and 7 deleted:
+
+```
+GET  /animals                                       -> 200  []      (nothing visible)
+GET  /animals/4                                     -> 404          (free — indistinguishable from hidden)
+POST /animals {"id":4}                              -> 403          (breaking change 3)
+POST /owners  {... pets:[{"id":9007199254740992}]}  -> 200          (#207 plants the ceiling record)
+POST /animals (no id)                               -> 200  id=4    <- names a hole in the hidden range
+POST /animals (no id)                               -> 200  id=7    <- and the other one
+POST /animals (no id)                               -> 200  id=13
+POST /animals (no id)                               -> 200  id=14
+```
+
+Closing this requires the assignment to be filter-aware, which is a change to
+the `access` contract rather than a fix; it is stated here rather than left to
+be discovered. Callers with no function-style filter are unaffected — there are
+no hidden records to disclose.
 
 ### Identifying the collection
 
@@ -512,14 +735,24 @@ sub-paths beneath the mount, as the `/archived` deny above does.
   one collection is writable and another is filtered on a field the first can
   set. Blocking it requires checking animal 21 against the **animal** model's
   predicate while servicing an **owners** route — cross-model access resolution,
-  which the current contract cannot express: `access()` never receives the model
-  structurally ([#202](https://github.com/abofs/stonyx-orm/issues/202)) and
-  `setup-rest-server.ts` discards the model→predicate map at boot
-  ([#196](https://github.com/abofs/stonyx-orm/issues/196)). Tracked as
-  [#207](https://github.com/abofs/stonyx-orm/issues/207), blocked on that chain
-  (#202 → #196 → #207). Until it lands, do not rely on a filter to keep a record
-  unmodifiable; keep the *writable* collections' predicates as tight as the
-  hidden ones.
+  which the contract could not express before
+  [#202](https://github.com/abofs/stonyx-orm/issues/202): `access()` never
+  received the model structurally and `setup-rest-server.ts` discarded the
+  model→predicate map at boot. **#202 has landed and both halves now exist** —
+  see [The access context](#the-access-context-second-argument):
+  `Orm.instance.getAccess(modelName)` makes another model's predicate
+  **reachable**, and `context.model` makes a **model-correct answer possible** —
+  possible, not guaranteed: the resolved predicate has to read the context, and
+  every predicate in tree is still single-argument
+  ([#213](https://github.com/abofs/stonyx-orm/issues/213)), so today it answers
+  about the collection the request is addressed to. **The mechanism exists; the
+  ORM does not yet use it on this path.** The re-parenting write above is still
+  **not refused** — that enforcement is
+  [#196](https://github.com/abofs/stonyx-orm/issues/196) and
+  [#207](https://github.com/abofs/stonyx-orm/issues/207), which were blocked on
+  #202 and are now free to proceed. Until they land, do not rely on a filter to
+  keep a record unmodifiable; keep the *writable* collections' predicates as tight as
+  the hidden ones.
 - **Authorization by identifying the collection is a consumer-side
   reconstruction of information the framework already holds.** `access()`
   receives a transport artifact and is asked to work out which model, which
@@ -565,9 +798,10 @@ sub-paths beneath the mount, as the `/archived` deny above does.
   transform output differs from its lookup key is the same defect. Filtered
   collections are unaffected — breaking change 3 refuses any client-supplied id
   — so this reaches consumers with **no** function-style filter. Tracked as
-  [#205](https://github.com/abofs/stonyx-orm/issues/205), alongside
-  [#203](https://github.com/abofs/stonyx-orm/issues/203), which is the other way
-  a create can land on an id nobody named.
+  [#205](https://github.com/abofs/stonyx-orm/issues/205). Its sibling
+  [#203](https://github.com/abofs/stonyx-orm/issues/203) — a **server-assigned**
+  id landing on an occupied slot — is **fixed**; see breaking change 8. #205 is
+  the client-supplied half and is still open.
 - **`context.record` is `undefined` for an after-`create` hook when a string-id
   model is given a numeric-looking id.** The post-create lookup uses the same id
   coercion as every other surface, which resolves `'9107'` to the number `9107`,
@@ -577,15 +811,18 @@ sub-paths beneath the mount, as the `/archived` deny above does.
   [#209](https://github.com/abofs/stonyx-orm/issues/209).
 - **A denied `POST` rolls back only a record it *inserted*.** The rollback
   requires the store to have grown, because removing by id alone is a write
-  primitive keyed by a caller-supplied value. When `assignRecordId` lands a
-  **server-assigned** id on an occupied slot
-  ([#203](https://github.com/abofs/stonyx-orm/issues/203) — it returns
-  last-*inserted* + 1, not max + 1, so a store whose insertion order is not
-  ascending collides), `createRecord` updates that record **in place**: the map
-  does not grow, the rollback correctly declines to remove a record this request
-  did not create, and the `403` leaves the caller's attributes on someone else's
-  record. Narrow — it needs a non-ascending insertion order — but it is the
-  reachability condition, so it is stated rather than implied.
+  primitive keyed by a caller-supplied value. **The reachability condition this
+  bullet used to state is gone**: it was
+  [#203](https://github.com/abofs/stonyx-orm/issues/203) — `assignRecordId`
+  returned last-*inserted* + 1, so a server-assigned id could land on an
+  occupied slot and `createRecord` would update it in place — and #203 is fixed
+  (breaking change 8). A server-assigned create can no longer overwrite, so on a
+  collection whose only id channel is `createHandler` this guard has no
+  observable effect today. It is kept because a caller-supplied id reaching
+  `createRecord` from another route — a relationship write,
+  [#207](https://github.com/abofs/stonyx-orm/issues/207) — puts the condition
+  back, and without the guard a denied `403` would delete a record the request
+  did not create.
 
 ### Breaking changes
 
@@ -646,6 +883,64 @@ they are recorded here.
    population breaking changes 3 and 4 explicitly exempt. If you were relying on
    a hex-shaped or whitespace-padded id creating a second record, it never did.
 
+8. **Server-assigned ids change value on string-id models, numeric ids stop
+   being monotonic at the numeric ceiling, and the create route gains a
+   `409`.** Three consumer-visible changes from
+   [#203](https://github.com/abofs/stonyx-orm/issues/203).
+
+   **The value.** A `POST` with no `id` against a model declaring
+   `id = attr('string')` previously produced the *last-inserted* id with `1`
+   concatenated onto it — an owner store holding `['gina', 'bob']` answered
+   `'bob1'`. It now answers `'owner-1'`: the model name, a hyphen, and the
+   lowest positive integer whose landing key is free. **No test in this repo
+   pinned the old value**, so a consumer relying on it gets no failing test, no
+   deprecation and no other signal — which is why it is recorded here. Numeric
+   id models (`id = attr('number')`, the default) are unaffected in shape: they
+   still get an integer, but it is now the **maximum** existing id plus one
+   rather than the last-inserted id plus one, which is the defect #203 is about.
+   They are **not** unaffected in *sequence* — see the monotonicity half below.
+
+   The value is deliberately **not** numeric-looking, and that is not cosmetic.
+   Every id-bearing surface resolves a numeric-looking string id to a **number**
+   (`GET /owners/1` looks up `1`), while a string-id model files its records
+   under the **string** key `'1'`. A server-assigned `'1'` would therefore be a
+   record that was created successfully and could not be fetched, updated or
+   deleted by id, and whose after-`create` hook received
+   `context.record === undefined`
+   ([#209](https://github.com/abofs/stonyx-orm/issues/209)).
+
+   **Numeric ids are no longer monotonic, and deleted ids can be re-issued.**
+   The precondition is narrow but it is reachable, and there is no signal when
+   it is met: **one record filed at or above 2^53** (`9007199254740992`). `max
+   + 1` is not representable there, so assignment restarts from `1` and walks
+   up to the lowest free key — which means the id of a *deleted* record is
+   handed to the next `POST`. Both `dev` and every prior release were strictly
+   monotonic and never re-issued a numeric id, so a consumer that relied on
+   that — audit rows, cursors, cached authorization decisions, external
+   references keyed on the id — now has a stale reference that silently points
+   at a **different record, created by a different caller**, rather than at a
+   deleted one. Nothing fails; the reference simply resolves to the wrong
+   record.
+
+   The restart is deliberate and is not itself optional: without it, one record
+   at the ceiling made every subsequent server-assigned create on that
+   collection fail permanently. Re-use is the cost of keeping the collection
+   writable. **If you need monotonic ids, assign them yourself** rather than
+   letting the server assign, and note that a ceiling record can be planted by
+   an unauthenticated caller — see *And the id itself is an occupancy signal*
+   under [Filter functions](#filter-functions) for the reachability path.
+   String-id models are unaffected by this half: their keys are
+   `<model>-<n>` and were never monotonic over an integer sequence.
+
+   **The status.** `POST /{collection}` can now answer `409` for a reason other
+   than a duplicate id: the server could not derive a free id. That requires a
+   **non-injective** id transform — one that maps distinct candidates onto the
+   same store key, such as `boolean`, or anything you registered on
+   `Orm.instance.transforms` and named as an id type. It is a configuration
+   fault rather than a request fault; the message is logged through
+   `stonyx/log`. Previously this case threw out of the handler and express
+   answered `500` with a stack trace.
+
 ### Include Parameter (Sideloading Relationships)
 
 The ORM supports JSON API-compliant relationship sideloading via the `include` query parameter. This reduces the need for multiple API requests by embedding related records in a single response.

package/dist/index.d.ts

@@ -9,6 +9,7 @@ import { count, avg, sum, min, max } from './aggregates.js';
 export { default } from './main.js';
 export { store, relationships } from './main.js';
 export type { PersistErrorDetail } from './main.js';
+export type { AccessContext, AccessFunction, AccessMethod, AccessOperation } from './types/orm-types.js';
 export { Model, View, Serializer };
 export { attr, belongsTo, hasMany, createRecord, updateRecord };
 export { count, avg, sum, min, max };

package/dist/main.d.ts

@@ -1,4 +1,5 @@
 import Store from './store.js';
+import type { AccessFunction } from './types/orm-types.js';
 interface OrmOptions {
     dbType?: string;
 }
@@ -32,12 +33,127 @@ export default class Orm {
     views: Record<string, unknown>;
     transforms: Record<string, (value: unknown) => unknown>;
     warnings: Set<string>;
+    /**
+     * Model name -> the `access` predicate of the access class that CLAIMS that
+     * model (abofs/stonyx-orm#202).
+     *
+     * Not "that model's own predicate". One access class may claim many models
+     * -- `GlobalAccess` in this repo's fixtures declares five, and `models = '*'`
+     * claims every model in the store -- and it declares ONE `access` method, so
+     * the same function object is registered under every one of those keys.
+     * `getAccess('owner') === getAccess('animal')` is `true` there. The
+     * one-to-one guarantee below is key -> function, never function -> model,
+     * and a caller must not read a resolved predicate as being animal-specific.
+     * What makes the ANSWER model-specific is the context the caller passes and
+     * the predicate actually reading it -- see {@link Orm#getAccess}.
+     *
+     * NAMED FOR WHAT IT HOLDS. It was `accessFiles` through review, inherited
+     * from the function-local in `setup-rest-server.ts` where the values came
+     * straight out of `forEachFileImport` and "files" was defensible. The values
+     * are `AccessFunction`s, and the sibling public registries on this class
+     * (`models`, `serializers`, `views`, `transforms`) are all plural nouns of
+     * the thing held. Renamed here because #202 is the last moment it is free.
+     *
+     * Populated by `setup-rest-server.ts` at boot, from the access classes under
+     * `config.orm.paths.access`, BEFORE any route is mounted -- so it is complete
+     * and reachable before the first request can be served. The mapping is
+     * one-to-one by construction: setup-rest-server throws if two access classes
+     * claim the same model.
+     *
+     * Keys are model names as declared and stored (kebab-case, e.g.
+     * `'phone-number'`), NOT pluralised or mount-prefixed route names.
+     *
+     * WHY THIS EXISTS AS A FIELD. It used to be a function-local in
+     * setup-rest-server that was discarded when that function returned, so at
+     * request time there was no way to get from a model name to that model's
+     * predicate at all. Each `OrmRequest` held only its OWN model's predicate.
+     * That made cross-model authorization -- asking model X's predicate about a
+     * request routed to model Y -- inexpressible, which is the capability
+     * abofs/stonyx-orm#196 and abofs/stonyx-orm#207 are built on.
+     *
+     * Empty when the REST server is disabled, and PARTIAL when one access file
+     * failed to load (`setup-rest-server.ts` catches, warns and assigns whatever
+     * it had). So a missing key does NOT mean the model has no access class.
+     * Prefer {@link Orm#getAccess} over indexing this directly -- it is guarded
+     * against the prototype chain and this is not.
+     */
+    accessFunctions: Record<string, AccessFunction>;
     options: OrmOptions;
     sqlDb?: SqlDb;
     db?: OrmDB | SqlDb;
     private _persistErrorHandler;
     constructor(options?: OrmOptions);
     init(): Promise<void>;
+    /**
+     * Resolve the `access` predicate registered for a model name
+     * (abofs/stonyx-orm#202).
+     *
+     * This is the supported way to reach another model's predicate while
+     * servicing a request routed to a different model. Call it with the model
+     * name and invoke the result with the live request and an explicit context
+     * naming THAT model:
+     *
+     * ```js
+     * const predicate = Orm.instance.getAccess('animal');
+     * if (!predicate) return deny;
+     * const verdict = predicate(request, { model: 'animal', operation: 'read' });
+     * ```
+     *
+     * WHAT IT RESOLVES. The predicate of the access CLASS that claims the model,
+     * which is not necessarily specific to it: one class may claim many models
+     * and declares one `access` method, so
+     * `getAccess('owner') === getAccess('animal')` is `true` against this repo's
+     * fixture. See {@link Orm#accessFunctions}.
+     *
+     * `undefined` means NO PREDICATE COULD BE RESOLVED for that name. That
+     * includes a model whose access class failed to LOAD -- `setup-rest-server`
+     * catches, warns and publishes the partial map -- so it is not the same claim
+     * as "this model is unrestricted". Treat it as DENY, the same way
+     * `AccessContext.operation === undefined` is treated.
+     *
+     * PASSING THE CONTEXT MAKES A MODEL-CORRECT ANSWER POSSIBLE. It does not, on
+     * its own, make the answer model-correct: the resolved predicate has to READ
+     * the context. Measured against this repo's shipped access class on a request
+     * express dispatched to `GET /owners/angela`, asked about ANIMALS:
+     *
+     * ```
+     * getAccess('animal')(ownersRequest, { model: 'animal', operation: 'read' })
+     *   ->  record => record.id !== 'angela' && record.id !== 'restricted'
+     * ```
+     *
+     * The OWNERS filter, which returns `true` for animal 21 -- the record hidden
+     * on every animal surface. Under a mount that predicate recognises neither
+     * way it falls through to `['read', 'create', 'update', 'delete']`, a full
+     * CRUD grant. Either way: context supplied, answer not the animal answer,
+     * wrong in the GRANTING direction, because that predicate is arity-1 and
+     * identifies its collection from the request. AC9 asserts the first case on a
+     * live dispatch.
+     *
+     * Every predicate in this repo and in every consumer tree is arity-1 today,
+     * and there is no supported way for the caller to tell which kind it got; the
+     * boot-time arity warning that would surface it is abofs/stonyx-orm#213. Pass
+     * the context, and do not treat a resolved predicate's answer as
+     * model-specific until that predicate reads it.
+     *
+     * OWN PROPERTIES ONLY. A bare `this.accessFunctions[modelName]` walks the
+     * prototype chain, so `getAccess('constructor')` resolved `Object` and
+     * `getAccess('toString')` resolved `Object.prototype.toString` -- both
+     * callable, and the documented `predicate?.(request, ctx)` pattern then
+     * returned a TRUTHY value (`Object(request)` is the request), bypassing the
+     * `undefined`-means-deny contract entirely. Nothing in the ORM calls
+     * `getAccess` yet, so it was not exploitable as shipped -- but #207 takes the
+     * model name from the REQUEST BODY (`data.relationships.<key>.data.type`),
+     * which would have made a one-field body an authorization bypass. Guarded
+     * here at the read point rather than by constructing the map with a null
+     * prototype, because the field is public and reassignable and the guard has
+     * to hold whatever object it is holding.
+     *
+     * @param modelName - Model name as declared and stored (kebab-case).
+     * @returns The predicate, or `undefined` when no predicate could be resolved
+     *   for that name. `undefined` is NOT "this model is unrestricted" -- see the
+     *   note above. Treat it as deny.
+     */
+    getAccess(modelName: string): AccessFunction | undefined;
     startup(): Promise<void>;
     shutdown(): Promise<void>;
     static get db(): OrmDB | SqlDb;