@stonyx/orm 0.3.2-alpha.6 → 0.3.2-alpha.61

package/dist/manage-record.js

@@ -52,13 +52,34 @@ export function createRecord(modelName, rawData = {}, userOptions = {}) {
             relationship.push(record);
         pendingHasMany.splice(0);
     }
+    // FK-based inverse hasMany wiring — when a child record is created with a
+    // foreign-key field (e.g. `owner: 'owner-1'` on an animal), find any parent
+    // whose hasMany registry targets this model and push the child into the
+    // parent's shared array.  This covers edge cases where the child is created
+    // in a separate async frame without a belongsTo handler firing.
+    const hasManyReg = getHasManyRegistry();
+    if (hasManyReg) {
+        for (const [parentModelName, targetMap] of hasManyReg) {
+            const childArrayMap = targetMap.get(modelName);
+            if (!childArrayMap)
+                continue;
+            // Check if rawData contains a FK field matching the parent model name
+            const fkValue = rawData[parentModelName];
+            if (fkValue === undefined || fkValue === null)
+                continue;
+            const parentArray = childArrayMap.get(fkValue);
+            if (parentArray && !parentArray.includes(record)) {
+                parentArray.push(record);
+            }
+        }
+    }
     // Fulfill pending belongsTo relationships
     const pendingBelongsToQueue = getPendingBelongsToRegistry();
     const pendingBelongsToRaw = pendingBelongsToQueue.get(modelName)?.get(record.id);
     const pendingBelongsTo = Array.isArray(pendingBelongsToRaw) ? pendingBelongsToRaw : undefined;
     if (pendingBelongsTo) {
         const belongsToReg = getBelongsToRegistry();
-        const hasManyReg = getHasManyRegistry();
+        const pendingHasManyReg = getHasManyRegistry();
         for (const { sourceRecord, sourceModelName, relationshipKey, relationshipId } of pendingBelongsTo) {
             // Update the belongsTo relationship on the source record
             sourceRecord.__relationships[relationshipKey] = record;
@@ -72,7 +93,7 @@ export function createRecord(modelName, rawData = {}, userOptions = {}) {
                 }
             }
             // Wire inverse hasMany if it exists
-            const inverseHasMany = hasManyReg.get(modelName)?.get(sourceModelName)?.get(record.id);
+            const inverseHasMany = pendingHasManyReg.get(modelName)?.get(sourceModelName)?.get(record.id);
             if (inverseHasMany && !inverseHasMany.includes(sourceRecord)) {
                 inverseHasMany.push(sourceRecord);
             }
@@ -83,14 +104,24 @@ export function createRecord(modelName, rawData = {}, userOptions = {}) {
     // Auto-persist to SQL — skip for DB loads (isDbRecord) and relationship resolution (_relationshipKey)
     const shouldPersist = orm?.sqlDb && !options.isDbRecord && !userOptions._relationshipKey && !options._skipAutoPersist;
     if (shouldPersist) {
+        // Capture ID before persist — SQL adapters re-key pending IDs to real DB IDs,
+        // but relationship registries were keyed with this original ID
+        const registryId = record.id;
         const response = { data: { id: record.id } };
-        orm.sqlDb.persist('create', modelName, { rawData }, response).catch((err) => {
+        orm.sqlDb.persist('create', modelName, { rawData }, response)
+            .catch((err) => {
             orm.emitPersistError({
                 operation: 'create',
                 modelName,
                 recordId: record.id,
                 error: err instanceof Error ? err : new Error(String(err)),
             });
+        })
+            .finally(() => {
+            // Evict non-memory records after persist to prevent unbounded heap growth (stonyx#81)
+            if (store._memoryResolver && !store._memoryResolver(modelName)) {
+                store.evictRecord(modelName, record.id, registryId);
+            }
         });
     }
     return record;
@@ -122,17 +153,52 @@ export function updateRecord(record, rawData, userOptions = {}) {
     }
 }
 /**
- * gets the next available id based on last record entry.
+ * gets the next available id, based on the HIGHEST id present.
  *
  * In MySQL mode with numeric IDs, assigns a temporary pending ID.
  * MySQL's AUTO_INCREMENT provides the real ID after INSERT.
+ *
+ * ---------------------------------------------------------------------------
+ * WAS: `Array.from(storeMap.values()).at(-1).id + 1` — the LAST INSERTED id,
+ * not the maximum (abofs/stonyx-orm#203). The store is a Map, so insertion
+ * order stops being ascending the moment a record is deleted and recreated, a
+ * db.json is written out of order, a directory-mode store is read back in file
+ * order, or a caller POSTs a high id and then a low one. After that, every
+ * server-assigned id is one that is ALREADY TAKEN — and `createRecord`'s
+ * last-entry-wins branch then overwrites that record IN PLACE and answers 200.
+ * No error, no 409, and the store's size does not change. That is the whole
+ * defect, and it is reachable from a create with NO id at all, which is the
+ * most ordinary write a consumer performs.
+ *
+ * Covered by test/unit/assign-record-id-test.ts. Note for anyone changing this
+ * function: before that file existed, the whole suite scored 951/0 both on the
+ * defect and on a naive `Math.max` fix that introduced a second one. A green
+ * suite is not evidence here; those assertions are.
+ * ---------------------------------------------------------------------------
  */
 function assignRecordId(modelName, rawData) {
-    if (rawData.id)
+    // PRESENCE, not truthiness. `0` is a legal value for an `attr('number')` id,
+    // and `if (rawData.id) return` silently reassigned it, handing the caller back
+    // a different record than the one it named (#203).
+    //
+    // `''` is deliberately NOT honoured here and this is not an oversight: it is
+    // the one string that means "no id". `parseInt('')` is `NaN`, a record CAN be
+    // held under the key `NaN`, and orm-request.ts's body-id normalisation relies
+    // on `''` staying absent — otherwise `POST {"id":""}` answers 409 against a
+    // record it never named. Pinned by test/unit/assign-record-id-test.ts (AC6's
+    // BOUNDARY assertions) and by access-filter-enforcement-test.ts assertion 44.
+    // Widening this to `!== undefined` breaks both.
+    if (rawData.id || rawData.id === 0)
         return;
     // In SQL mode with numeric IDs, defer to database auto-increment.
     // Use unique negative integers — they survive the number transform (parseInt preserves negatives)
     // and avoid NaN store-key collisions that string pending IDs caused.
+    //
+    // This early return is ABOVE the max computation on purpose: a pending
+    // negative must never be a candidate for, or be perturbed by, the max path.
+    // Pinned directly (AC5.3) rather than by asserting the max is unaffected —
+    // that assertion could not have failed, because nothing negative ever reaches
+    // the code below.
     if (Orm.instance?.sqlDb && !isStringIdModel(modelName)) {
         rawData.id = -(++pendingIdCounter);
         rawData.__pendingSqlId = true;
@@ -142,13 +208,73 @@ function assignRecordId(modelName, rawData) {
     if (!storeMap)
         throw new Error(`Cannot assign record ID: model "${modelName}" not found in store`);
     const modelStore = Array.from(storeMap.values()).filter(isOrmRecord);
-    const lastRecord = modelStore.at(-1);
-    rawData.id = lastRecord ? lastRecord.id + 1 : 1;
+    // The shape of src/standalone-db.ts:134-137, and it is chosen over
+    // `Math.max(...ids)` for a reason that is measurable rather than stylistic:
+    // a store CAN hold a record under the key `NaN` (`{id: '   '}` is truthy, so
+    // it survives the guard above and NaNs in the number transform — that is the
+    // state access-filter-enforcement-test.ts assertion 44 constructs). `Math.max`
+    // returns `NaN` if any operand is `NaN`, so it would assign `NaN`, land on
+    // that slot and overwrite it — exactly the defect being fixed, in a new
+    // disguise. This reduce cannot: non-numbers are skipped, and `NaN > max` is
+    // `false`. Pinned by AC2.
+    const maxId = modelStore.reduce((max, record) => {
+        const recordId = record.id;
+        return typeof recordId === 'number' && recordId > max ? recordId : max;
+    }, 0);
+    // THE OCCUPANCY CHECK RUNS ON THE LANDING KEY, NOT ON THE RAW CANDIDATE, and
+    // the difference is a silent data loss rather than a nicety.
+    //
+    // `createRecord` looks the record up under `rawData.id` (:50) but WRITES it
+    // under `record.id` (:69) — the value after the model's declared id transform
+    // has run inside `serialize`. On a string-id model those two differ: the
+    // number `1` is looked up, the record lands under the string `'1'`. A guard
+    // written as `storeMap.has(rawData.id)` therefore checks a key the record will
+    // never occupy, misses an occupied slot and overwrites it — measured: owner
+    // '1' age 55 -> 9, store size unchanged, no error. That is abofs/stonyx-orm
+    // #205's lookup-key/landing-key divergence reappearing inside #203's own fix,
+    // which is why AC4 exists and why `rawData.id` is set to the LANDING key
+    // below: it makes :50 and :69 agree by construction.
+    //
+    // Termination: with an injective id transform at most `storeMap.size`
+    // candidates can be occupied. A NON-injective id type would otherwise spin
+    // forever, so the loop is bounded and exits with a defined error the route can
+    // report instead of hanging the request.
+    //
+    // Resolved ONCE, outside the loop: `getIdType` instantiates the model class,
+    // so resolving it per candidate would put a model construction on every
+    // iteration of a loop that exists to walk past occupied slots.
+    const toStoreKey = storeKeyDeriver(modelName);
+    let candidate = maxId + 1;
+    let landingKey = toStoreKey(candidate);
+    let attempts = 0;
+    while (storeMap.has(landingKey)) {
+        if (++attempts > storeMap.size) {
+            throw new Error(`Cannot assign record ID: no free id available for model "${modelName}"`);
+        }
+        candidate += 1;
+        landingKey = toStoreKey(candidate);
+    }
+    rawData.id = landingKey;
 }
-function isStringIdModel(modelName) {
-    const modelClass = Orm.instance.getRecordClasses(modelName).modelClass;
+/**
+ * Returns the derivation that maps an id VALUE to the store KEY a record
+ * carrying it will actually be filed under — the model's declared id transform,
+ * the same one `serialize` runs at createRecord:68 before the `.set` at :69.
+ */
+function storeKeyDeriver(modelName) {
+    const idType = getIdType(modelName);
+    const transform = idType ? Orm.instance?.transforms?.[idType] : undefined;
+    if (typeof transform !== 'function')
+        return value => value;
+    return value => transform(value);
+}
+function getIdType(modelName) {
+    const modelClass = Orm.instance?.getRecordClasses(modelName).modelClass;
     if (!modelClass)
-        return false;
+        return undefined;
     const model = new modelClass(modelName);
-    return model.id?.type === 'string';
+    return model.id?.type;
+}
+function isStringIdModel(modelName) {
+    return getIdType(modelName) === 'string';
 }

package/dist/mysql/connection.d.ts

@@ -8,6 +8,7 @@ interface MysqlConfig {
     connectionLimit?: number;
     migrationsTable?: string;
     migrationsDir?: string;
+    autoMigrate?: boolean;
 }
 export declare function getPool(mysqlConfig: MysqlConfig): Promise<Pool>;
 export declare function closePool(): Promise<void>;

package/dist/mysql/mysql-db.d.ts

@@ -61,6 +61,14 @@ export default class MysqlDB {
     deps: MysqlDBDeps;
     pool: Pool | null;
     mysqlConfig: MysqlConfig;
+    /**
+     * Promise-chain mutex for write serialization (#156).
+     * All persist() calls chain through this single queue so concurrent
+     * fire-and-forget writes never produce parallel InnoDB transactions
+     * on FK-linked rows (which cause deadlocks).
+     * Reads are NOT affected — only persist() serializes.
+     */
+    private _writeQueue;
     constructor(deps?: Partial<MysqlDBDeps>);
     private requirePool;
     init(): Promise<void>;

package/dist/mysql/mysql-db.js

@@ -26,6 +26,14 @@ export default class MysqlDB {
     deps;
     pool;
     mysqlConfig;
+    /**
+     * Promise-chain mutex for write serialization (#156).
+     * All persist() calls chain through this single queue so concurrent
+     * fire-and-forget writes never produce parallel InnoDB transactions
+     * on FK-linked rows (which cause deadlocks).
+     * Reads are NOT affected — only persist() serializes.
+     */
+    _writeQueue = Promise.resolve();
     constructor(deps = {}) {
         if (MysqlDB.instance)
             return MysqlDB.instance;
@@ -57,7 +65,17 @@ export default class MysqlDB {
         const pending = files.filter(f => !applied.includes(f));
         if (pending.length > 0) {
             this.deps.log.db?.(`${pending.length} pending migration(s) found.`);
-            const shouldApply = await this.deps.confirm(`${pending.length} pending migration(s) found. Apply now?`);
+            let shouldApply;
+            if (this.mysqlConfig.autoMigrate === true) {
+                shouldApply = true;
+            }
+            else if (this.mysqlConfig.autoMigrate === false) {
+                shouldApply = false;
+                this.deps.log.warn?.(`autoMigrate is false — skipping ${pending.length} pending migration(s).`);
+            }
+            else {
+                shouldApply = await this.deps.confirm(`${pending.length} pending migration(s) found. Apply now?`);
+            }
             if (shouldApply) {
                 for (const filename of pending) {
                     const content = await this.deps.readFile(this.deps.path.join(migrationsPath, filename));
@@ -76,7 +94,17 @@ export default class MysqlDB {
             const schemas = this.deps.introspectModels();
             const modelCount = Object.keys(schemas).length;
             if (modelCount > 0) {
-                const shouldGenerate = await this.deps.confirm(`No migrations found but ${modelCount} model(s) detected. Generate and apply initial migration?`);
+                let shouldGenerate;
+                if (this.mysqlConfig.autoMigrate === true) {
+                    shouldGenerate = true;
+                }
+                else if (this.mysqlConfig.autoMigrate === false) {
+                    shouldGenerate = false;
+                    this.deps.log.warn?.(`autoMigrate is false — skipping initial migration generation for ${modelCount} model(s).`);
+                }
+                else {
+                    shouldGenerate = await this.deps.confirm(`No migrations found but ${modelCount} model(s) detected. Generate and apply initial migration?`);
+                }
                 if (shouldGenerate) {
                     const { generateMigration } = await import('./migration-generator.js');
                     const result = await generateMigration('initial_setup');
@@ -302,14 +330,20 @@ export default class MysqlDB {
         const Orm = (await import('@stonyx/orm')).default;
         if (Orm.instance?.isView?.(modelName))
             return;
-        switch (operation) {
-            case 'create':
-                return this._persistCreate(modelName, context, response);
-            case 'update':
-                return this._persistUpdate(modelName, context, response);
-            case 'delete':
-                return this._persistDelete(modelName, context);
-        }
+        const work = async () => {
+            switch (operation) {
+                case 'create':
+                    return this._persistCreate(modelName, context, response);
+                case 'update':
+                    return this._persistUpdate(modelName, context, response);
+                case 'delete':
+                    return this._persistDelete(modelName, context);
+            }
+        };
+        // Chain through the write queue — .then(work, work) ensures the queue
+        // advances even when a previous persist rejects (#156).
+        this._writeQueue = this._writeQueue.then(work, work);
+        return this._writeQueue;
     }
     async _persistCreate(modelName, context, response) {
         const schemas = this.deps.introspectModels();

package/dist/orm-request.d.ts

@@ -1,4 +1,183 @@
+/**
+ * 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
+ * you to work out which collection it addresses. Every attempt to do that by
+ * parsing the request target has failed OPEN. Five distinct variants of the
+ * same three-line example have now been found, each after the previous was
+ * fixed, by five different people:
+ *
+ *   1. `request.url` is mount-relative under `RestServer.mountRoute`, so a
+ *      prefix match against it is ALWAYS false.
+ *   2. `request.originalUrl` carries the query string, so an anchored equality
+ *      check misses `/owners?filter[age]=30`.
+ *   3. The router is a bare `express()` (`caseSensitive: false`) while a
+ *      hand-written matcher is case-SENSITIVE, so `GET /OwNeRs/angela` walks
+ *      past it. Router-side: abofs/stonyx-rest-server#47.
+ *   4. Under a configured `ORM_REST_ROUTE` a hard-coded `/owners` matches
+ *      nothing -- environment-specifically, which is worse.
+ *   5. HTTP/1.1 permits an ABSOLUTE-FORM request-target. Express routes on
+ *      `parseurl(req).pathname`, but `originalUrl` is the raw target, so
+ *      `GET http://anything.example/owners/angela` reaches the handler with
+ *      `originalUrl === 'http://anything.example/owners/angela'`. A `/owners`
+ *      prefix match is false, `access()` falls through to whatever it returns
+ *      last, and the record comes back in full. It walks past a hard
+ *      `return false` deny the same way.
+ *
+ * The fix is not a sixth rule. It is to stop parsing:
+ *
+ *   `request.baseUrl` is the mount Express ACTUALLY MATCHED when it dispatched
+ *   the request. It carries no query string, it is not mount-relative, it is
+ *   unaffected by absolute-form, and it already includes the configured
+ *   `ORM_REST_ROUTE` prefix -- so there is nothing to derive and nothing to
+ *   join. Compare it lower-cased (the router matched case-insensitively) and
+ *   fail CLOSED when it is absent. Use `request.path` -- mount-relative and
+ *   query-free -- if you need to distinguish sub-paths.
+ *
+ * `?? ''` is not a defence. It converts an absent request target into an empty
+ * string, which matches no collection, which falls through to the permission
+ * array -- a total grant. An input you cannot identify must DENY.
+ *
+ * THAT IS STILL A STOPGAP. `baseUrl` closes all five variants, but it is a
+ * transport artifact being asked to stand in for a structural fact.
+ * THE REAL FIX IS abofs/stonyx-orm#202: `access()` should receive the model,
+ * the operation and the record. Prefer the array shape (`['read']`) or `false`
+ * until #202 lands; the function shape is what requires any matching at all.
+ *
+ * The enforcement gates in this file (GATE 0/1/2, the create rollback, the
+ * per-handler `isDenied` re-checks) are correct independently of that -- they
+ * enforce whatever predicate you return. The stopgap is the part where YOU have
+ * to work out which predicate to return.
+ *
+ * AND A PREDICATE IS NOT A GUARANTEE THAT A HIDDEN RECORD CANNOT BE MODIFIED.
+ * It is evaluated against the record the route is ADDRESSED TO, on that model
+ * only. A write to a DIFFERENT collection can still re-parent a hidden record
+ * and de-hide it -- abofs/stonyx-orm#207, which is blocked on #202 and #196.
+ * See `### Known limitations` in README.
+ */
 import { Request } from '@stonyx/rest-server';
+import type { AccessFunction } from './types/orm-types.js';
 interface OrmRequest$ extends Request {
     protocol?: string;
     method: string;
@@ -13,13 +192,12 @@ interface OrmRequest$ extends Request {
     };
     get(header: string): string;
 }
-type AccessMethod = string | boolean | string[] | ((record: unknown) => boolean);
 type HandlerFn = (request: OrmRequest$, state: {
     [key: string]: unknown;
 }) => unknown | Promise<unknown>;
 export default class OrmRequest extends Request {
     model: string;
-    access: (request: unknown) => AccessMethod;
+    access: AccessFunction;
     handlers: {
         [key: string]: {
             [key: string]: HandlerFn;
@@ -27,7 +205,7 @@ export default class OrmRequest extends Request {
     };
     constructor({ model, access }: {
         model: string;
-        access: (request: unknown) => AccessMethod;
+        access: AccessFunction;
     });
     private _withHooks;
     private _generateRelationshipRoutes;