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

package/dist/orm-request.js

@@ -2,6 +2,124 @@
  * REST request handling and access enforcement for @stonyx/orm.
  *
  * ---------------------------------------------------------------------------
+ * THE `access()` CONTRACT: `access(request, { model, operation })`
+ * ---------------------------------------------------------------------------
+ * `auth()` calls your predicate with TWO arguments. The second is the access
+ * CONTEXT -- the structural facts about the request, which the framework
+ * already holds and which you should read INSTEAD of parsing anything:
+ *
+ *   context.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
+ *                     pluralised, dasherized, mount-prefixed ROUTE name. It is
+ *                     read from the OrmRequest instance, fixed at mount time,
+ *                     and no request can influence it.
+ *
+ *   context.operation The operation being authorised. Exactly one of the four
+ *                     verbs `'read'`, `'create'`, `'update'`, `'delete'` --
+ *                     no second vocabulary ON THIS PATH, and never an HTTP
+ *                     method name like `'GET'`. These are the same four
+ *                     strings the permission-array return shape is written in
+ *                     (`['read', 'create']`), because both come from the one
+ *                     `methodAccessMap` below.
+ *
+ *                     NOT the hook vocabulary. `HookContext.operation`
+ *                     (`src/hooks.ts`, documented under "Hook Context Object"
+ *                     in the README) carries `'list' | 'get' | 'create' |
+ *                     'update' | 'delete'` on an identically-named key of an
+ *                     identically-shaped context object, and the access
+ *                     vocabulary collapses `list` and `get` into `'read'`. For
+ *                     one `GET /animals/1` a hook sees `'get'` and `access()`
+ *                     sees `'read'`, so a predicate cannot tell a collection
+ *                     read from a record read. `AccessOperation` makes
+ *                     `operation === 'get'` a compile error for a TypeScript
+ *                     consumer, because a predicate that stops matching falls
+ *                     through to the permission array -- the misreading is
+ *                     fail-open shaped.
+ *
+ *                     `undefined` when the dispatched method has no entry in
+ *                     that map. Express delivers `HEAD` to the `GET` handler,
+ *                     so this is reachable. It is left undefined rather than
+ *                     defaulted on purpose -- a fabricated `'read'` would turn
+ *                     an unclassified request into an authorised one. Treat
+ *                     `undefined` as "not classified" and deny.
+ *
+ * So a consumer writes `if (model === 'owner' && operation === 'read')`. There
+ * is no string to parse, no variant to miss, and no way to fail open through a
+ * URL shape nobody anticipated.
+ *
+ * WHAT THE CONTEXT DOES NOT TELL YOU: WHICH SURFACE. It names the model and
+ * the verb, not the 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` -- which is
+ * mount-relative and query-free, and is the one read of argument one the
+ * warning below sanctions. This repo's own fixture 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, turning a deny into an
+ * allow. The related-resource and `?include=` surfaces serve ANOTHER model's
+ * records under `model: 'owner'`, and the context gives no signal of that
+ * (abofs/stonyx-orm#196).
+ *
+ * `record` IS NOT IN THIS CONTEXT, deliberately. `auth()` runs after route
+ * matching but BEFORE any handler executes (`@stonyx/rest-server`
+ * `src/request.ts:58-60`), so nothing has been fetched yet -- supplying a
+ * record would force a pre-fetch on every request, a second store hit 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.
+ *
+ * THE SECOND ARGUMENT IS ADDITIVE. JavaScript ignores extra arguments, so an
+ * existing `access(request)` predicate keeps working exactly as before. The
+ * warning immediately below is therefore still live: `request` is still
+ * argument ONE, and reading it is still how predicates fail open.
+ *
+ * To reach ANOTHER model's predicate -- e.g. to check an animal while servicing
+ * an owners route -- use the boot-time registry:
+ *
+ *     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 for that name -- which
+ * includes the case where the model has an access class that failed to load,
+ * because `setup-rest-server.ts` catches a load failure, warns, and publishes
+ * whatever partial map it had. It does NOT mean the model is unrestricted.
+ * Treat it as DENY, the same way `operation === undefined` is treated above.
+ *
+ * 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 it.
+ * Measured against this repo's own 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'
+ *
+ * That is the OWNERS filter, and it returns `true` for animal 21 -- the record
+ * hidden on every animal surface. Under a mount that predicate recognises
+ * neither way it is worse: 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 GRANTING direction, because that predicate is arity-1 and identifies
+ * its collection from the request. (The first of these is asserted on a live
+ * dispatch by AC9 in test/integration/orm-test.ts.)
+ *
+ * Every predicate in this repo and in every consumer tree is arity-1 on the day
+ * this ships, and the caller has no supported way to tell which kind it got --
+ * the boot-time arity warning that would surface it is abofs/stonyx-orm#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 the context.
+ *
+ * ---------------------------------------------------------------------------
  * DO NOT RECONSTRUCT THE REQUEST PATH INSIDE `access()`.
  * ---------------------------------------------------------------------------
  * `auth()` below hands your `access(request)` a raw transport artifact and asks
@@ -1036,9 +1154,41 @@ export default class OrmRequest extends Request {
         // answers 500 -- and the documented sample itself can throw
         // (`request.originalUrl.split(...)` when originalUrl is absent), so the
         // failure mode is reachable by following the docs.
+        // -------------------------------------------------------------------------
+        // #202 -- hand the consumer the STRUCTURAL facts, not just the transport.
+        //
+        // Both members are already in hand here. `model` is `this.model`, the name
+        // setup-rest-server mounted this route for; `operation` is the SAME
+        // `methodAccessMap` lookup the permission-array branch at the bottom of
+        // this method performs, so the predicate form and the array form cannot
+        // answer differently about the same request.
+        //
+        // NEITHER IS DERIVED FROM THE REQUEST TARGET, and that is the whole point.
+        // Deriving `model` here from `request.baseUrl` (or from the mounted route
+        // name, or from `getPluralName(this.model)`) would move all five fail-open
+        // variants listed in this file's header OUT of the consumer and INTO the
+        // framework, where every consumer inherits them at once. `this.model` is
+        // assigned once at mount time and no request can influence it.
+        //
+        // `operation` is left UNDEFINED for a method with no entry in
+        // `methodAccessMap`, rather than defaulted. Express delivers HEAD to the
+        // GET handler, so an unmapped method really does reach this line; a
+        // `?? 'read'` here would hand the consumer a fabricated authorisation fact
+        // and turn an unclassified request into an authorised one. Undefined is
+        // the honest answer.
+        //
+        // `record` is deliberately absent -- see `AccessContext` in
+        // src/types/orm-types.ts. Nothing is fetched at this point and adding a
+        // lookup here would put a store read in the middle of an authorization
+        // path. The function return shape below IS the per-record hook.
+        // -------------------------------------------------------------------------
+        const context = {
+            model: this.model,
+            operation: methodAccessMap[request.method],
+        };
         let access;
         try {
-            access = this.access(request);
+            access = this.access(request, context);
         }
         catch (error) {
             // Same reasoning as `isDenied`: fail closed, but say so. An `access()`

package/dist/setup-rest-server.js

@@ -1,5 +1,5 @@
 import { waitForModule } from 'stonyx';
-import { store } from '@stonyx/orm';
+import Orm, { store } from '@stonyx/orm';
 import OrmRequest from './orm-request.js';
 import MetaRequest from './meta-request.js';
 import RestServer from '@stonyx/rest-server';
@@ -8,7 +8,7 @@ import { dbKey } from './db.js';
 import { getPluralName } from './plural-registry.js';
 import log from 'stonyx/log';
 export default async function (route, accessPath, metaRoute) {
-    const accessFiles = {};
+    const accessFunctions = {};
     try {
         await forEachFileImport(accessPath, (accessClass) => {
             const accessInstance = new accessClass();
@@ -25,9 +25,9 @@ export default async function (route, accessPath, metaRoute) {
                     continue;
                 if (!store.data.has(model))
                     throw new Error(`Unable to define access for Invalid Model "${model}". Model does not exist`);
-                if (accessFiles[model])
+                if (accessFunctions[model])
                     throw new Error(`Access for model "${model}" has already been defined by another access class.`);
-                accessFiles[model] = accessInstance.access;
+                accessFunctions[model] = accessInstance.access;
             }
         });
     }
@@ -35,11 +35,57 @@ export default async function (route, accessPath, metaRoute) {
         log.error?.(error instanceof Error ? error.message : String(error));
         log.warn?.('You must define a valid access configuration file in order to access ORM generated REST endpoints.');
     }
+    // -------------------------------------------------------------------------
+    // #202 -- the registry has to survive this function.
+    //
+    // `accessFunctions` used to be a function-local that was discarded at the return
+    // below, so the only thing that ever saw it was the mount loop. Each mounted
+    // OrmRequest then held its OWN model's predicate and nothing held the map, so
+    // at request time there was no route from a model NAME to that model's
+    // predicate -- which is what abofs/stonyx-orm#196 and #207 need in order to
+    // ask model X's predicate about a request routed to model Y.
+    //
+    // Published BEFORE `await waitForModule('rest-server')`, deliberately: that
+    // await is the ONLY yield point in this function, and the rest-server module
+    // may already be listening by the time it reports ready, so an assignment
+    // after it would leave a window in which a route is live and the registry is
+    // not.
+    //
+    // It is NOT before the mount loop for that reason, and the comment here used
+    // to say it was. `RestServer.mountRoute` is fully synchronous -- construct,
+    // registerCalls(), api.use() -- and nothing between the loop and this
+    // function's closing brace yields, so the event loop cannot deliver a request
+    // in there and the window that clause described cannot open. Measured:
+    // moving this assignment to the last statement of the function leaves the
+    // suite at 951 pass / 0 fail. Being ahead of the mount loop is free and
+    // harmless; it is not what makes the ordering correct.
+    //
+    // Assigned unconditionally, including when the try above failed and the map
+    // is empty or partial: the mount loop below is driven by this exact object,
+    // so at the moment of assignment whatever is reachable through
+    // `Orm.instance` is the same set of predicates that is about to enforce.
+    // A guard such as `if (Object.keys(accessFunctions).length)` would let the
+    // registry go silently missing on a total load failure, and a later consumer
+    // would read `undefined` from `getAccess` and have to distinguish "no access
+    // class" from "the registry was never published" -- which it cannot. That is
+    // the reasoning, and it is REASONING, not something this suite tests: the
+    // guarded variant is also 951 pass / 0 fail, AC8 included, because every boot
+    // in this suite loads a non-empty access map so the guard never fires. AC8
+    // demonstrably cannot catch it. Catching it needs a boot with
+    // `orm.paths.access` pointed at an empty directory, which this suite has no
+    // harness for.
+    //
+    // One further limit on "by construction": the mount loop passes `access` BY
+    // VALUE into each OrmRequest, so the enforcing set is a snapshot taken here,
+    // while `getAccess` reads the map live. The two are the same set at boot and
+    // stay the same set only for as long as nobody writes to the public field.
+    // The equality is a boot-time fact, not an invariant.
+    Orm.instance.accessFunctions = accessFunctions;
     await waitForModule('rest-server');
     // Remove "/" prefix and name mount point accordingly
     const name = route === '/' ? 'index' : (route[0] === '/' ? route.slice(1) : route);
     // Configure endpoints for models and views with access configuration
-    for (const [model, access] of Object.entries(accessFiles)) {
+    for (const [model, access] of Object.entries(accessFunctions)) {
         const pluralizedModel = getPluralName(model);
         const modelName = name === 'index' ? pluralizedModel : `${name}/${pluralizedModel}`;
         RestServer.instance.mountRoute(OrmRequest, { name: modelName, options: { model, access } });

package/dist/types/orm-types.d.ts

@@ -162,3 +162,104 @@ export interface SnapshotEntry {
     source?: string;
     viewQuery?: string;
 }
+/**
+ * The shapes a consumer `access()` predicate may return.
+ *
+ * - `false` (or any falsy value) -- deny, 403.
+ * - `true` -- allow, with no per-record filter.
+ * - a permission string or array of them, drawn from the same four verbs as
+ *   {@link AccessContext.operation}. A BARE STRING IS ONE PERMISSION, not a
+ *   grant of all four.
+ * - a `(record) => boolean` predicate -- allow, and filter every record the
+ *   request touches through it.
+ *
+ * Anything else fails CLOSED. See `src/orm-request.ts` `auth()`.
+ */
+export type AccessMethod = string | boolean | string[] | ((record: unknown) => boolean);
+/**
+ * The closed vocabulary `AccessContext.operation` is drawn from
+ * (abofs/stonyx-orm#202).
+ *
+ * A literal union rather than `string`, so the guarantee the prose makes is the
+ * one the compiler enforces: a consumer who writes `operation === 'GET'` or
+ * `operation === 'get'` -- the hook vocabulary, see below -- gets a compile
+ * error instead of a comparison that never matches. A predicate that stops
+ * matching falls through to the permission array, so the misreading is
+ * fail-open shaped.
+ *
+ * In-repo precedent: `PersistErrorDetail.operation` in `src/main.ts`.
+ */
+export type AccessOperation = 'read' | 'create' | 'update' | 'delete';
+/**
+ * The structural facts about the request being authorised, handed to a consumer
+ * `access()` predicate as its SECOND argument (abofs/stonyx-orm#202).
+ *
+ * These are the facts the framework already holds at authorisation time. Before
+ * #202 a consumer had to reconstruct both of them by string-matching a URL, and
+ * five independent fail-open variants of that reconstruction were found in one
+ * three-line documented example -- each one wrong in the direction that GRANTS
+ * access. Read these instead; there is nothing to parse and no variant to miss.
+ *
+ * `record` is deliberately NOT a member. `auth()` runs after route matching but
+ * before any handler executes (`@stonyx/rest-server` `src/request.ts:58-60`),
+ * so nothing has been fetched yet -- carrying a record here would force a
+ * pre-fetch on every request. It is also unnecessary: the `(record) => boolean`
+ * return shape of {@link AccessMethod} already IS the per-record hook, applied
+ * by the handlers. Auth-time and record-time are separate decision points.
+ */
+export interface AccessContext {
+    /**
+     * The model this route was mounted for, e.g. `'owner'` or `'phone-number'`.
+     *
+     * Model names are kebab-case, as declared under `config.orm.paths.model` and
+     * keyed in the store -- NOT the pluralised, mount-prefixed route name. It is
+     * read from the `OrmRequest` instance and is never derived from the request
+     * target, so a mount prefix, a case-varied path, a query string or an
+     * absolute-form request-target cannot change it.
+     */
+    model: string;
+    /**
+     * The operation being authorised. Exactly one of the four {@link
+     * AccessOperation} verbs, or `undefined`. These are exactly the values of
+     * `methodAccessMap` in `src/orm-request.ts`, which is also what the
+     * permission-array return shape is matched against -- so the two forms cannot
+     * disagree.
+     *
+     * NOT the hook vocabulary. `HookContext.operation` (`src/hooks.ts`) carries
+     * `'list' | 'get' | 'create' | 'update' | 'delete'` on an identically-named
+     * key of an identically-shaped context object, and the access vocabulary
+     * collapses `list` and `get` into `'read'`. For one `GET /animals/1` a hook
+     * sees `'get'` and `access()` sees `'read'`. "No second vocabulary" is a
+     * statement about the ACCESS path only.
+     *
+     * `undefined` when the dispatched method has no entry in that map. Express
+     * delivers `HEAD` to the `GET` handler, so this is reachable. It is left
+     * undefined rather than defaulted on purpose: a fabricated `'read'` would
+     * turn an unclassified request into an authorised one.
+     *
+     * The KEY is required even though the value may be undefined: `auth()` always
+     * sets it, and a context that simply omitted it would be indistinguishable
+     * from one that classified the request and found nothing.
+     */
+    operation: AccessOperation | undefined;
+}
+/**
+ * A consumer `access()` predicate.
+ *
+ * The second argument is ADDITIVE: JavaScript ignores extra arguments, so every
+ * pre-#202 single-argument predicate keeps working untouched. Changing the
+ * FIRST argument instead would have been the breaking form, and a predicate
+ * that can no longer identify its collection falls through to a full CRUD
+ * grant -- so the "safer" breaking change would have converted every unmigrated
+ * predicate into a fail-open.
+ *
+ * `context` is nonetheless REQUIRED in the type, and that costs back-compat
+ * nothing. TypeScript already lets a fewer-parameter implementation satisfy a
+ * more-parameter signature, so an arity-1 predicate assigns to this type
+ * cleanly -- measured under `--strict`. What the `?` bought was the opposite of
+ * safety: it silently permitted `getAccess('animal')?.(request)` at the CALL
+ * site, i.e. exactly the omission {@link AccessContext} exists to prevent, and
+ * that call gets the model-wrong answer. Required, a caller that drops the
+ * context gets `TS2554: Expected 2 arguments, but got 1`.
+ */
+export type AccessFunction = (request: unknown, context: AccessContext) => AccessMethod;

package/package.json

@@ -4,7 +4,7 @@
     "stonyx-async",
     "stonyx-module"
   ],
-  "version": "0.3.2-beta.153",
+  "version": "0.3.2-beta.154",
   "description": "",
   "main": "dist/index.js",
   "type": "module",

package/src/index.ts

@@ -27,6 +27,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'; // access() contract (#202)
 export { Model, View, Serializer }; // base classes
 export { attr, belongsTo, hasMany, createRecord, updateRecord }; // helpers
 export { count, avg, sum, min, max }; // aggregate helpers

package/src/main.ts

@@ -25,6 +25,7 @@ import baseTransforms from './transforms.js';
 import Store from './store.js';
 import Serializer from './serializer.js';
 import { setup } from '@stonyx/events';
+import type { AccessFunction } from './types/orm-types.js';
 
 interface OrmOptions {
   dbType?: string;
@@ -68,6 +69,53 @@ export default class Orm {
   views: Record<string, unknown> = {};
   transforms: Record<string, (value: unknown) => unknown> = { ...baseTransforms };
   warnings: Set<string> = new Set();
+
+  /**
+   * 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;
@@ -195,6 +243,81 @@ export default class Orm {
     Orm.initialized = true;
   }
 
+  /**
+   * 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 {
+    if (!Object.hasOwn(this.accessFunctions, modelName)) return undefined;
+
+    return this.accessFunctions[modelName];
+  }
+
   async startup(): Promise<void> {
     if (this.sqlDb) await this.sqlDb.startup();
   }