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

package/src/record.ts

@@ -1,29 +1,12 @@
 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';
 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 {
@@ -55,25 +38,6 @@ interface JSONAPIResult {
   links?: { self: string };
 }
 
-
-/**
- * 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: unknown): string {
-  if (verdict === null) return 'null';
-  if (Array.isArray(verdict)) return 'an array';
-
-  if ((typeof verdict === 'object' || typeof verdict === 'function')
-    && typeof (verdict as { then?: unknown }).then === 'function') return 'a Promise (or other thenable)';
-
-  return `a value of type ${typeof verdict}`;
-}
-
 export default class Record {
   /** @private */
   __data: { [key: string]: unknown } = {};
@@ -152,13 +116,7 @@ export default class Record {
   toJSON(options: ToJSONOptions = {}): JSONAPIResult {
     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);
@@ -177,143 +135,12 @@ export default class Record {
       attributes[key] = (getter as () => unknown).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: string) => {
-      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: LinkageFilter | undefined = !linkageSupplied
-      ? undefined
-      : linkageUsable ? linkage as LinkageFilter : () => 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: Record): boolean => {
-      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: Record) => r?.__model).filter(isLinkable).map((r: Record) => ({ type: r.__model.__name, id: r.id }))
-        : (childRecord && (childRecord as Record).__model && isLinkable(childRecord as Record)) ? { type: (childRecord as Record).__model.__name, id: (childRecord as Record).id } : null;
+        ? childRecord.filter((r: Record) => r?.__model).map((r: Record) => ({ type: r.__model.__name, id: r.id }))
+        : (childRecord && (childRecord as Record).__model) ? { type: (childRecord as Record).__model.__name, id: (childRecord as Record).id } : null;
 
       // Dasherize the key for URL paths (e.g., accessLinks -> access-links)
       const dasherizedKey = camelCaseToKebabCase(key);

package/src/setup-rest-server.ts

@@ -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';
@@ -7,20 +7,14 @@ import { forEachFileImport } from '@stonyx/utils/file';
 import { dbKey } from './db.js';
 import { getPluralName } from './plural-registry.js';
 import log from 'stonyx/log';
-import type { AccessFunction } from './types/orm-types.js';
 
 interface AccessInstance {
   models: string[] | '*';
-  /**
-   * The consumer predicate. Called as `access(request, { model, operation })`
-   * -- the second argument is additive (abofs/stonyx-orm#202), so a predicate
-   * declared with a single parameter is still valid and still works.
-   */
-  access: AccessFunction;
+  access: (request: unknown) => unknown;
 }
 
 export default async function(route: string, accessPath: string, metaRoute: boolean): Promise<void> {
-  const accessFunctions: Record<string, AccessFunction> = {};
+  const accessFiles: Record<string, (request: unknown) => unknown> = {};
 
   try {
     await forEachFileImport(accessPath, (accessClass: unknown) => {
@@ -37,9 +31,9 @@ export default async function(route: string, accessPath: string, metaRoute: bool
       for (const model of models === '*' ? availableModels : models) {
         if (model === dbKey) continue;
         if (!store.data.has(model)) throw new Error(`Unable to define access for Invalid Model "${model}". Model does not exist`);
-        if (accessFunctions![model]) throw new Error(`Access for model "${model}" has already been defined by another access class.`);
+        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;
       }
     });
   } catch (error) {
@@ -47,60 +41,13 @@ export default async function(route: string, accessPath: string, metaRoute: bool
     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/src/standalone-db.ts

@@ -8,10 +8,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';
 
 interface StandaloneDBOptions {
   dbPath?: string;
@@ -135,19 +131,12 @@ export default class StandaloneDB {
     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

package/src/types/orm-types.ts

@@ -89,15 +89,7 @@ export interface OrmRecord {
   __model?: { __name: string };
   __data: Record<string, unknown> & { id?: string | number; __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>;
+  toJSON?(options?: { fields?: Set<string>; baseUrl?: string }): Record<string, unknown>;
   [key: string]: unknown;
 }
 
@@ -176,250 +168,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/src/types/stonyx-rest-server.d.ts

@@ -5,20 +5,7 @@ declare module '@stonyx/rest-server' {
 
   interface RouteOptions {
     name: string;
-    /**
-     * `access` is the two-argument post-#202 shape. This is the THIRD place the
-     * contract is declared (`AccessInstance.access` in
-     * `src/setup-rest-server.ts` and `OrmRequest.access` in
-     * `src/orm-request.ts` are the other two) and it is the one `mountRoute` is
-     * actually called through, at `src/setup-rest-server.ts`. It kept the
-     * pre-#202 single-argument signature after the other two migrated; the
-     * union with `Record<string, unknown>` meant nothing broke, which is
-     * exactly why it would have drifted silently.
-     *
-     * Spelled structurally rather than as `AccessFunction`: an ambient
-     * `declare module` block cannot carry an `import type`.
-     */
-    options?: { model: string; access: (request: unknown, context: { model: string; operation: string | undefined }) => unknown } | Record<string, unknown>;
+    options?: { model: string; access: (request: unknown) => unknown } | Record<string, unknown>;
   }
 
   export default class RestServer {