@stonyx/orm 0.3.2-beta.160 → 0.3.2-beta.161

package/dist/record.d.ts

@@ -1,23 +1,7 @@
 import type Serializer from './serializer.js';
-import type { LinkageFilter } from './types/orm-types.js';
 interface ToJSONOptions {
     fields?: Set<string>;
     baseUrl?: string;
-    /**
-     * An ALREADY-RESOLVED linkage decision, supplied by a caller that holds the
-     * request (abofs/stonyx-orm#234). Returning `false` for a related record
-     * drops that record's `{ type, id }` from `relationships.*.data`.
-     *
-     * This method APPLIES a verdict; it never RESOLVES one -- see
-     * `src/access-verdict.ts` for the two measured reasons it cannot. ABSENT is
-     * the default and the default is TODAY'S DOCUMENT, unchanged, because
-     * `toJSON` is also the `JSON.stringify` hook and an implicit caller has no
-     * syntactic place to pass this (abofs/stonyx-orm#230).
-     *
-     * ABSENT and UNUSABLE are read differently, and the difference is a security
-     * decision -- see the three-way reading at the call site below.
-     */
-    linkage?: LinkageFilter;
 }
 interface SerializeOptions {
     update?: boolean;

package/dist/record.js

@@ -1,26 +1,7 @@
 import { store } from '@stonyx/orm';
-import log from 'stonyx/log';
 import { getComputedProperties } from "./serializer.js";
 import { camelCaseToKebabCase } from '@stonyx/utils/string';
 import { getPluralName } from './plural-registry.js';
-/**
- * Name a non-boolean `linkage` return for the one log line that reports it.
- *
- * A thenable is called out BY NAME because it is the shape a consumer produces
- * by accident -- an `async` resolver, or one that returns the promise of an
- * authorization lookup -- and the one whose truthiness silently GRANTED every
- * relationship before the ANSWER was checked (abofs/stonyx-orm#234).
- */
-function describeNonVerdict(verdict) {
-    if (verdict === null)
-        return 'null';
-    if (Array.isArray(verdict))
-        return 'an array';
-    if ((typeof verdict === 'object' || typeof verdict === 'function')
-        && typeof verdict.then === 'function')
-        return 'a Promise (or other thenable)';
-    return `a value of type ${typeof verdict}`;
-}
 export default class Record {
     /** @private */
     __data = {};
@@ -84,13 +65,7 @@ export default class Record {
     toJSON(options = {}) {
         if (!this.__serialized)
             throw new Error('Record must be serialized before being converted to JSON');
-        // DESTRUCTURED FROM A VALUE THAT IS NOT ALWAYS AN OBJECT. `toJSON` is the
-        // ECMAScript serialization hook, so `JSON.stringify({ data: record })`
-        // arrives here as `toJSON('data')` -- a STRING in the options slot.
-        // Destructuring a string yields `undefined` for every key, which is exactly
-        // the no-argument default, so the implicit path keeps working and keeps
-        // emitting today's document (abofs/stonyx-orm#230).
-        const { fields, baseUrl, linkage } = options;
+        const { fields, baseUrl } = options;
         const { __data: data } = this;
         const modelName = this.__model.__name;
         const pluralizedModelName = getPluralName(modelName);
@@ -109,133 +84,12 @@ export default class Record {
                 continue;
             attributes[key] = getter.call(this);
         }
-        // `linkage` is a PUBLIC option -- it is on `OrmRecord.toJSON`
-        // (src/types/orm-types.ts) and the README tells consumers to pass one -- so
-        // it arrives from outside this package, may be ANY value, and whatever it
-        // is, it gets INVOKED here. That makes this the trust boundary, and it was
-        // the LAX side of one: the internal `createLinkageFilter` coerces and
-        // try/catches the consumer predicate it wraps, while this -- the site that
-        // consumes the PUBLIC option -- did neither.
-        //
-        // THREE QUESTIONS. Every wrong answer below was measured, on a two-
-        // relationship record, emitting the full pre-#234 document or throwing out
-        // of `JSON.stringify`.
-        //
-        //   1. IS IT SUPPLIED? ABSENT (`undefined`) means no verdict was supplied:
-        //      emit today's document. Load-bearing and asserted (AC5/AC5b) --
-        //      `toJSON` is also the `JSON.stringify` hook, so the implicit caller
-        //      arrives as `toJSON('data')`, a STRING, which destructures to
-        //      `undefined` here (abofs/stonyx-orm#230).
-        //
-        //   2. IS ITS SHAPE USABLE? `[object Function]` only, because
-        //      `typeof x === 'function'` is NOT the question "can this answer a
-        //      synchronous boolean".
-        //
-        //      A NON-FUNCTION denies. Reading it as absent is what `!linkage ||`
-        //      did, and a resolver returning `null` because it could not resolve a
-        //      session is the natural shape of that value and the fail-closed
-        //      INTENT -- measured, `toJSON({ linkage: null })` emitted the full
-        //      pre-#234 linkage with no signal, byte-identical to unpatched dev.
-        //
-        //      AN `AsyncFunction`, `GeneratorFunction` or `AsyncGeneratorFunction`
-        //      denies for that SAME reason, one branch over -- and a `typeof`-only
-        //      check left the whole defect standing there. `async (type, r) =>
-        //      false` returns a PROMISE, a promise is TRUTHY, so every relationship
-        //      was emitted in full with ZERO log, again byte-identical to unpatched
-        //      dev. An awaited authorization lookup is at least as natural a
-        //      resolver as a nullish one -- the README's own Consumer Contracts
-        //      section points consumers at queue payloads and websocket frames,
-        //      where lookups are routinely awaited -- and it landed on the GRANT
-        //      side of the same branch the `null` reading closed.
-        //
-        //   3. IS ITS ANSWER A VERDICT? It must BE a boolean, not merely coerce to
-        //      one. `Boolean(...)` -- the coercion `createLinkageFilter` applies to
-        //      a consumer `access()` predicate, whose truthy contract predates this
-        //      option and is deliberately NOT changed -- is not enough here, and
-        //      was measured not to be: with `Boolean(...)` plus a try/catch in
-        //      place, `async () => false`, `function* () {}`,
-        //      `() => Promise.resolve(false)`, `() => ({})` and `() => 'no'` ALL
-        //      still emitted the full pre-#234 linkage with no log, because
-        //      truthiness is what they already had. A non-boolean is a resolver
-        //      that did not answer, and the only safe reading of a non-answer is a
-        //      denial.
-        //
-        // AND IT NEVER THROWS -- which is now true rather than only written down.
-        // A throw here escapes the enclosing `JSON.stringify` and takes
-        // `console.log` and `Orm.db.save()`'s neighbours with it, a far worse
-        // failure mode than a status. `class Klass {}`, `Klass.bind(null)` and any
-        // predicate that dereferences something undefined were all measured raising
-        // out of the `stringify`; all three are caught and denied.
-        //
-        // Logged once per DOCUMENT, not once per relationship key or per related
-        // record: an emptied relationship is deliberately indistinguishable from a
-        // genuinely empty one on the wire, so the log is the ONLY signal a consumer
-        // whose resolver quietly returned `null`, or a promise, will ever get.
-        const linkageSupplied = linkage !== undefined;
-        // Read the tag DEFENSIVELY. `Object.prototype.toString` consults
-        // `Symbol.toStringTag`, so a Proxy with a throwing `get` trap would throw
-        // out of the validation whose entire job is that nothing throws.
-        let linkageShape = 'a non-function';
-        if (typeof linkage === 'function') {
-            try {
-                linkageShape = Object.prototype.toString.call(linkage);
-            }
-            catch {
-                linkageShape = '[object Unreadable]';
-            }
-        }
-        const linkageUsable = linkageShape === '[object Function]';
-        let linkageReported = false;
-        const denyAllLinkage = (reason) => {
-            if (linkageReported)
-                return;
-            linkageReported = true;
-            log.error?.(`[@stonyx/orm] toJSON() received an unusable \`linkage\` option -- ${reason}, so ALL relationship linkage on this \`${modelName}\` document is denied.`);
-        };
-        if (linkageSupplied && !linkageUsable) {
-            denyAllLinkage(typeof linkage !== 'function'
-                ? `it is of type ${linkage === null ? 'null' : typeof linkage} and it must be a function`
-                : `it is ${linkageShape} and it must be a SYNCHRONOUS function -- \`toJSON\` is the \`JSON.stringify\` hook and cannot await a verdict`);
-        }
-        const linkageVerdict = !linkageSupplied
-            ? undefined
-            : linkageUsable ? linkage : () => false;
-        // Applied per related record, alongside the existing `__model` liveness
-        // check, and producing exactly the shapes that check already produces: a
-        // dropped hasMany member leaves `data: []`, a dropped belongsTo leaves
-        // `data: null`. Both already ship -- a genuinely-empty hasMany emits
-        // `data: []` with links, and a cleaned belongsTo emits `data: null` -- so a
-        // filtered relationship is BYTE-IDENTICAL to an empty one and there is no
-        // new wire shape and no oracle.
-        const isLinkable = (r) => {
-            if (!linkageVerdict)
-                return true;
-            try {
-                const verdict = linkageVerdict(r.__model.__name, r);
-                if (typeof verdict === 'boolean')
-                    return verdict;
-                denyAllLinkage(`it answered with ${describeNonVerdict(verdict)} rather than a boolean`);
-            }
-            catch (error) {
-                // Building the report is itself a throw site -- `throw Symbol('x')`
-                // makes `String(error)` throw, and a getter on `.message` can throw --
-                // and a throw from the reporter would escape the catch that exists so
-                // that nothing escapes.
-                let detail = 'a value that could not be described';
-                try {
-                    detail = error instanceof Error ? error.message : String(error);
-                }
-                catch { /* keep the fallback -- the denial matters, the text does not */ }
-                denyAllLinkage(`it threw (${detail})`);
-            }
-            return false;
-        };
         for (const [key, childRecord] of Object.entries(this.__relationships)) {
             if (fields && !fields.has(key))
                 continue;
             const relationshipData = Array.isArray(childRecord)
-                ? childRecord.filter((r) => r?.__model).filter(isLinkable).map((r) => ({ type: r.__model.__name, id: r.id }))
-                : (childRecord && childRecord.__model && isLinkable(childRecord)) ? { type: childRecord.__model.__name, id: childRecord.id } : null;
+                ? childRecord.filter((r) => r?.__model).map((r) => ({ type: r.__model.__name, id: r.id }))
+                : (childRecord && childRecord.__model) ? { type: childRecord.__model.__name, id: childRecord.id } : null;
             // Dasherize the key for URL paths (e.g., accessLinks -> access-links)
             const dasherizedKey = camelCaseToKebabCase(key);
             relationships[dasherizedKey] = { data: relationshipData };

package/dist/setup-rest-server.js

@@ -1,5 +1,5 @@
 import { waitForModule } from 'stonyx';
-import Orm, { store } from '@stonyx/orm';
+import { 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 accessFunctions = {};
+    const accessFiles = {};
     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 (accessFunctions[model])
+                if (accessFiles[model])
                     throw new Error(`Access for model "${model}" has already been defined by another access class.`);
-                accessFunctions[model] = accessInstance.access;
+                accessFiles[model] = accessInstance.access;
             }
         });
     }
@@ -35,57 +35,11 @@ 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(accessFunctions)) {
+    for (const [model, access] of Object.entries(accessFiles)) {
         const pluralizedModel = getPluralName(model);
         const modelName = name === 'index' ? pluralizedModel : `${name}/${pluralizedModel}`;
         RestServer.instance.mountRoute(OrmRequest, { name: modelName, options: { model, access } });

package/dist/standalone-db.js

@@ -7,10 +7,6 @@
  */
 import fs from 'fs/promises';
 import path from 'path';
-// `./utils.js` pulls in `@stonyx/utils/string` and nothing else -- no ORM
-// bootstrap, no `@stonyx/orm` index, no side effects -- so the "no framework
-// dependencies" property above still holds.
-import { maxNumericId } from './utils.js';
 export default class StandaloneDB {
     mode;
     dbPath;
@@ -106,19 +102,11 @@ export default class StandaloneDB {
     async create(collection, data) {
         const records = await this.readCollection(collection);
         if (!data.id) {
-            // SHARED WITH `assignRecordId` (src/manage-record.ts), which is the other
-            // place this repo picks a server-assigned id. It was a second copy of the
-            // reduce, and nothing here pointed at it — a maintainer editing this
-            // method could not discover the other existed. See `maxNumericId` for why
-            // it is not `Math.max` (abofs/stonyx-orm#203).
-            //
-            // THE TWO ARE NOT THE SAME FUNCTION beyond this line, deliberately.
-            // `StandaloneDB` has no model, id-type or transform concept, so `maxId + 1`
-            // IS its store key; `assignRecordId` has to map the candidate through the
-            // model's declared id transform first, and then walk past occupied keys.
-            // Transplanting this method's remaining logic into the ORM reproduces
-            // #203's landing-key defect exactly — which is what AC4 pins.
-            data.id = maxNumericId(records) + 1;
+            const maxId = records.reduce((max, r) => {
+                const rid = typeof r.id === 'number' ? r.id : 0;
+                return rid > max ? rid : max;
+            }, 0);
+            data.id = maxId + 1;
         }
         // Check for duplicate id
         const existing = records.find(r => r.id === data.id);

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

@@ -87,18 +87,9 @@ export interface OrmRecord {
         __pendingSqlId?: boolean;
     };
     __relationships: Record<string, unknown>;
-    /**
-     * `linkage` is an ALREADY-RESOLVED decision supplied by a caller that holds
-     * the request (abofs/stonyx-orm#234): return `false` for a related record and
-     * its `{ type, id }` is dropped from `relationships.*.data`. Omitting it is
-     * the default, and the default is the pre-#234 document unchanged -- this
-     * method is also the `JSON.stringify` hook, so an implicit caller has no
-     * syntactic place to pass it (abofs/stonyx-orm#230).
-     */
     toJSON?(options?: {
         fields?: Set<string>;
         baseUrl?: string;
-        linkage?: LinkageFilter;
     }): Record<string, unknown>;
     [key: string]: unknown;
 }
@@ -171,243 +162,3 @@ 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;
-    /**
-     * The record this route was addressed to, as the store key -- or `null` on a
-     * collection route, which is addressed to no record (abofs/stonyx-orm#236).
-     *
-     * IT IS ALREADY DECODED, AND THAT IS THE WHOLE POINT. Express decodes route
-     * PARAMETERS while leaving `request.path` raw, so a consumer comparing
-     * `request.path` against a literal compares an undecoded string against a
-     * decoded dispatch. `GET /owners/%61rchived` reached such a comparison as
-     * `/%61rchived`, walked past a `/archived` deny, and was dispatched as the
-     * record `archived` -- 200 with the record in full, and `DELETE` destroyed
-     * it, unauthenticated. 255 non-canonical spellings of an 8-character id
-     * decode to the same key, so a deny-list of spellings is the wrong shape.
-     *
-     * SO DO NOT NORMALISE THIS, AND DO NOT NORMALISE ANYTHING ELSE INSTEAD:
-     *
-     * - Do NOT decode it. Express decodes exactly ONCE, which is what a route
-     *   parameter means. `GET /owners/%2561rchived` is the legitimate id
-     *   `%61rchived`, not a second-order spelling of `archived`; a predicate that
-     *   decoded until stable would deny a record it was never asked about.
-     * - Do NOT case-fold it. A record id is a VALUE, not a literal route segment,
-     *   and express's `case sensitive routing` governs literal segments only.
-     *   With a distinct owner seeded at `ARCHIVED`, `.toLowerCase()` was measured
-     *   wrong in BOTH directions at once: `GET /owners/ARCHIVED` 403 (a false
-     *   deny, on the wrong record) and `GET /owners/%41RCHIVED` 200 (a false
-     *   allow, on that same record).
-     * - Do NOT derive it from `request.path` or the request target. Decoding the
-     *   whole path decodes THEN splits, while the router splits THEN decodes, so
-     *   `/owners/archived%2fx` -- a genuinely distinct record whose id is
-     *   `archived/x` -- was measured over-denied 403.
-     *
-     * IT IS `getId(request.params)`, BYTE FOR BYTE -- the same single coercion
-     * the store lookup uses, exactly as `operation` is the same `methodAccessMap`
-     * lookup the permission-array branch uses. The predicate and the dispatch
-     * therefore cannot disagree about which record a request addresses. Handing
-     * over the raw `request.params.id` instead would reintroduce that divergence
-     * on hex-shaped ids: `GET /animals/0x2391` looks up record `9105`.
-     *
-     * It inherits abofs/stonyx-orm#209 along with that coercion -- on a model
-     * declaring `id = attr('string')`, `'9107'` arrives here as the number
-     * `9107`. That is consistency WITH THE LOOKUP, which is the property this key
-     * exists to buy; it is not a defect to repair here.
-     *
-     * `null`, not `undefined`, on a collection route -- and the KEY IS ALWAYS
-     * PRESENT, the same rule `operation` states above. `auth()` always sets it,
-     * so a context arriving WITHOUT the key did not come from `auth()`: it was
-     * hand-assembled by a caller resolving the predicate through
-     * `Orm.instance.getAccess()`. That absence stays a distinguishable, deniable
-     * signal only because the framework never produces it.
-     *
-     * IT DISAGREES WITH THE HOOK VOCABULARY, AND NOT ONLY ON THE ABSENCE
-     * SPELLING. `HookContext.recordId` (`src/hooks.ts`) is an identically-named
-     * key on an identically-shaped context object, which is the exact
-     * configuration that makes `operation` fail-open shaped -- a hook sees
-     * `'get'` where `access()` sees `'read'`. An earlier revision of THIS
-     * docblock asserted the opposite ("here they AGREE... they differ in ONE way
-     * and it is the absence spelling"). That was measured false, in the fail-open
-     * direction, and it is corrected here rather than deleted.
-     *
-     * MEASURED over the live dispatch, before-hooks registered for all five
-     * operations on one model:
-     *
-     *     before:list    key ABSENT      ('recordId' in context === false)
-     *     before:get     key ABSENT      params={"id":"visible1"}
-     *     before:create  key ABSENT
-     *     before:update  key ABSENT      params={"id":"visible2"}
-     *     before:delete  recordId="visible3"
-     *     after:delete   recordId="visible3"
-     *
-     * `_withHooks` assigns `context.recordId` at exactly TWO sites in
-     * `src/orm-request.ts`, and BOTH sit inside an `operation === 'delete'`
-     * branch. So the two keys differ in COVERAGE, on four of five operations: on
-     * a hook context the key is absent for get, list, create and update, while
-     * this key is present on every route `auth()` classifies. The absence
-     * spelling is the smaller half of the difference, not the whole of it.
-     *
-     * AND THAT INVERTS THE ARGUMENT ABOVE WHEN IT IS READ ACROSS THE TWO. Here,
-     * a missing `recordId` means "did not come from `auth()`" and is deniable.
-     * On a hook context it means "this is a get / list / create / update" -- an
-     * ordinary request. A consumer who writes the hook-side half of the same
-     * rule --
-     *
-     *     beforeHook('update', 'owner', ctx => ctx.recordId === 'archived' ? 403 : undefined)
-     *
-     * -- gets a deny that NEVER FIRES: measured, `PATCH /owners/visible2` -> 200,
-     * with `ctx.recordId === undefined` while the addressed record sits in
-     * `ctx.params`. The hook side is abofs/stonyx-orm#242 and is deliberately not
-     * repaired here. A predicate must not read `undefined` here as "collection",
-     * and nothing in this contract makes it safe to read the two keys as one key.
-     *
-     * IT NAMES WHICH RECORD OF THE MODEL BEING ASKED ABOUT, NOT WHICH SURFACE,
-     * AND THE ANSWER DEPENDS ON WHICH MODEL IS BEING ASKED ABOUT.
-     *
-     * For the ask about the ROUTE'S OWN model, all three of `GET /owners/gina`,
-     * `GET /owners/gina/pets` and `GET /owners/gina/relationships/pets` carry
-     * `recordId: 'gina'` -- `auth()` reads it off `request.params`.
-     *
-     * FOR THE ASK ABOUT A RELATED MODEL, IT IS `null`, AND THAT IS A LIMIT ON
-     * WHAT A PREDICATE CAN EXPRESS (abofs/stonyx-orm#232). The two relationship
-     * route families resolve the RELATED model's own predicate -- `animal` on
-     * `GET /owners/gina/pets`, `owner` on `GET /animals/4/owner` -- and that ask
-     * carries `recordId: null` while `request.params` names a record of a
-     * DIFFERENT model. So a predicate answering about a related model gets the
-     * model name, the operation and the request, and CANNOT branch on which
-     * related record it is being asked about.
-     *
-     * The rule, so it is not re-derived wrong: `recordId` may name a record only
-     * where the route addresses exactly one record OF THE MODEL BEING ASKED
-     * ABOUT. A `hasMany` related-resource route returns many records of one type
-     * and the verdict is resolved ONCE PER TYPE, before any record is examined --
-     * seeding it from a record would let the first one decide for all of them.
-     *
-     * What still works, and what does not, is pinned as behaviour by `#232 AC10`
-     * in test/integration/orm-test.ts and stated for consumers in README.md:
-     * model-level denies work, request-level denies work, and the per-record
-     * FILTER shape works because `access()` may return a function and that
-     * function receives the whole record. Branching on identity BEFORE returning
-     * does not.
-     *
-     * `?include=` is a separate surface and is abofs/stonyx-orm#233 / #235.
-     */
-    recordId: string | number | null;
-}
-/**
- * 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;
-/**
- * A resolved, request-scoped linkage decision: may `record` of model `type` be
- * NAMED, by id, inside another model's document (abofs/stonyx-orm#234)?
- *
- * Arity is `(type, record)` and not `(type, id)` because the per-record filter
- * a consumer returns is handed the RECORD -- this repo's own fixture reads
- * `record.owner?.id`, not just `record.id`. The `(type, id)` pair is the CACHE
- * key inside `createLinkageFilter`, not the input.
- *
- * DECLARED HERE, with the rest of the access vocabulary, and imported by every
- * site that names it. It had three structurally-identical hand-written copies
- * (`access-verdict.ts`, `record.ts`, `OrmRecord.toJSON` below) bridged to each
- * other by nothing, so a drift in nullability or a widening of `type` would
- * have landed on one and not the others -- which is the same "second,
- * unreviewed vocabulary" failure `src/access-verdict.ts` exists to prevent, one
- * level up in the type system.
- */
-export type LinkageFilter = (type: string, record: unknown) => boolean;

package/dist/utils.d.ts

@@ -5,47 +5,3 @@ export declare function isDbError(error: unknown): error is {
 };
 export declare function isOrmRecord(value: unknown): value is OrmRecord;
 export declare function pluralize(word: string): string;
-/**
- * The highest NUMERIC id held by a set of records, or `0` when there is none.
- *
- * ONE COPY, and the duplication it replaces is the reason it lives here. Three
- * near-identical reduces existed at once: `assignRecordId` (server-assigned id
- * selection), `StandaloneDB.create` (src/standalone-db.ts) and the #203 test
- * helper. `docs/improvements.md`'s standing WET Code category prescribes
- * exactly this remedy -- extract into the module that already acts as the
- * shared utility -- and `assignRecordId` already imported `isOrmRecord` from
- * here.
- *
- * NON-NUMBERS ARE SKIPPED RATHER THAN COERCED TO `0`, AND THAT IS STYLISTIC.
- * `StandaloneDB`'s shape mapped them to `0`, which can never beat a seed of
- * `0`. Measured over eleven input classes (`[]`, `1`, `NaN`, `'5'`, `'abc'`,
- * `-3`, `0`, `null`, `undefined`, `Infinity`, and mixed arrays) the two shapes
- * produce IDENTICAL output on every one. In particular `typeof NaN` is
- * `'number'`, so NEITHER shape coerces `NaN` -- both reject it on `NaN > max`,
- * which is `false`. An earlier revision of this code asserted that the skip was
- * what made the `NaN` case work; it is not, the comparison is, and that claim
- * has been removed rather than left standing.
- *
- * WHAT IS LOAD-BEARING is that this is not `Math.max(...ids)`. `Math.max`
- * returns `NaN` if any operand is `NaN`, and a record CAN be held under the key
- * `NaN` -- so the obvious fix assigns `NaN`, lands on that slot and overwrites
- * it, which is abofs/stonyx-orm#203 in a new disguise. Pinned by
- * test/unit/assign-record-id-test.ts AC2; before that file existed the whole
- * suite scored 951/0 under exactly that fix.
- */
-export declare function maxNumericId(records: {
-    id?: unknown;
-}[]): number;
-/**
- * The message prefix `assignRecordId` throws with when no free id can be
- * derived for a model, and the ONE string `createHandler` matches on to answer
- * `409` instead of letting the rejection reach express's default handler.
- *
- * It lives here rather than in either file because both need it and neither
- * should own a copy: a literal in two places is how the two id coercions in
- * orm-request.ts drifted apart (see `coerceId`). The repo has no error codes
- * and no custom error classes -- 24 bare `throw new Error` sites across `src/`
- * -- so a shared prefix is the narrowest way to make ONE failure distinguishable
- * without inventing an error taxonomy this codebase does not use.
- */
-export declare const NO_FREE_ID_ERROR = "Cannot assign record ID: no free id available";