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

package/dist/orm-request.js

@@ -69,6 +69,15 @@
  * records under `model: 'owner'`, and the context gives no signal of that
  * (abofs/stonyx-orm#196).
  *
+ * SUPERSEDED 2026-09-01 BY abofs/stonyx-orm#236/#237, AND KEPT FOR THE
+ * CONSTRAINT IT STATES RATHER THAN AS A DESCRIPTION OF THE CODE. The context
+ * now also carries `recordId` -- the DECODED route-parameter id, see
+ * `AccessContext.recordId` in ./types/orm-types.ts -- so the fixture's
+ * `/archived` deny IS expressible from the context alone, and the shipped
+ * sample no longer reads `request.path` at all. Retiring this wording WITH the
+ * measurement that retires it, rather than by deletion, is
+ * abofs/stonyx-orm#238.
+ *
  * `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
@@ -98,8 +107,8 @@
  *
  * 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:
+ * Measured against an ARITY-1 predicate, 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'
@@ -110,23 +119,30 @@
  * `['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.)
+ * its collection from the request. (Asserted on a live dispatch by AC9 in
+ * test/integration/orm-test.ts, against a deliberately arity-1 predicate.)
  *
- * 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.
+ * This repo's own sample access class has since been MIGRATED to read the
+ * context (abofs/stonyx-orm#222), so `getAccess('animal')` here now answers
+ * with the animal filter. That is not true of a consumer tree: an arity-1
+ * predicate keeps working -- the second argument is additive -- and the caller
+ * has no supported way to tell which kind it got. The boot-time arity warning
+ * that surfaces one is abofs/stonyx-orm#221.
  * 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:
+ * You do not have to. `auth()` below hands your predicate the ACCESS CONTEXT as
+ * argument two, and `context.model` already names the collection -- see the
+ * contract section above. Argument ONE is still the raw transport artifact, and
+ * everything from here to the end of this banner is the record of what happened
+ * when predicates worked the collection out from it. IT IS HISTORY, NOT
+ * GUIDANCE: do not write any of it into a new predicate. Every attempt to
+ * identify the collection 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.
@@ -145,22 +161,89 @@
  *      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:
+ * The fix is not a sixth rule, and it is not a better string to match. It is to
+ * stop identifying the collection at all: read `context.model`. That is a claim
+ * about IDENTIFYING THE COLLECTION, not about the sample as a whole -- the
+ * `/archived` SUB-PATH rule is still a string match, and abofs/stonyx-orm#228 is
+ * a sixth spelling that gets past it.
+ *
+ * SUPERSEDED 2026-09-01 BY abofs/stonyx-orm#236/#237: the `/archived` rule is
+ * no longer a string match against the request target -- it compares the
+ * decoded `recordId` the framework supplies -- and abofs/stonyx-orm#228 is
+ * CLOSED. Retirement of this wording: abofs/stonyx-orm#238.
+ *
+ *   An intermediate revision of the sample read `request.baseUrl` -- the mount
+ *   Express ACTUALLY MATCHED. That closed all five variants (no query string,
+ *   not mount-relative, unaffected by absolute-form, already carrying the
+ *   configured `ORM_REST_ROUTE` prefix), but it was a transport artifact
+ *   standing in for a structural fact and the sample no longer does it.
+ *   `context.model` IS the structural fact, so variants 1, 2, 4 and 5 are
+ *   unconstructible against a migrated predicate rather than handled.
+ *
+ *   VARIANT 3 SURVIVES, and is deliberately not in that list. It is the general
+ *   shape "a hand-written matcher normalises differently from the router", and a
+ *   migrated predicate still runs one string comparison for any SUB-PATH rule --
+ *   in the shipped sample, the `/archived` deny. That comparison folds case but
+ *   does not decode, so `GET /owners/%61rchived` steps past it. See the
+ *   normalisation paragraph below and abofs/stonyx-orm#228.
+ *
+ *   SUPERSEDED 2026-09-01 BY abofs/stonyx-orm#236/#237. Variant 3 lived in that
+ *   one string comparison, and the comparison is gone: the sample compares the
+ *   decoded `recordId`. Left standing rather than edited because the same
+ *   "variant 3 survives" wording sits at four sites -- this header, README.md
+ *   twice, and test/sample/access/global-access.ts -- three of which SHIP, so
+ *   retiring one of four leaves the shipped copies contradicting each other.
+ *   Retiring all four WITH their measurement is abofs/stonyx-orm#238.
+ *
+ * ONE READ OF ARGUMENT ONE SURVIVES, AND IT MUST: `request.path`. It is
+ * mount-relative and query-free, and it is for rules that distinguish SUB-PATHS
+ * beneath the mount. The context names which model and which verb, NOT which
+ * route, so the sample's `/archived` deny cannot be expressed from the context
+ * alone and a context-ONLY rewrite would silently turn that deny into an allow.
+ *
+ * SUPERSEDED 2026-09-01 BY abofs/stonyx-orm#236/#237: NO read of argument one
+ * survives in the shipped sample. `recordId` names WHICH RECORD the route was
+ * addressed to, so the `/archived` deny is expressible from the context alone
+ * -- and it still must not be dropped; expressible is not optional. Retirement
+ * of this wording: abofs/stonyx-orm#238.
+ *
+ * NORMALISE THE WAY THE ROUTER DOES, AND CASE-FOLDING ALONE IS NOT THAT. The
+ * sample lower-cases before comparing, because a matcher stricter than the
+ * case-insensitive router can be stepped around. That closes the case gap only.
+ * Express sets `request.path` from the RAW, UNDECODED pathname while the router
+ * DECODES `:id`, so `GET /owners/%61rchived` reaches a `path === '/archived'`
+ * comparison as `/%61rchived` and walks past the deny. That gap is live in the
+ * sample and is tracked as abofs/stonyx-orm#228; the `.toLowerCase()` is not a
+ * complete normalisation recipe. Compare record ids at their real case.
  *
- *   `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.
+ * DO NOT FOLLOW THE PARAGRAPH ABOVE. SUPERSEDED 2026-09-01 BY
+ * abofs/stonyx-orm#236/#237, and flagged here rather than merely dated because
+ * it is an INSTRUCTION, not a stale observation. `.toLowerCase()` on the access
+ * path was measured WRONG IN BOTH DIRECTIONS AT ONCE: with a distinct owner
+ * seeded at `ARCHIVED`, `GET /owners/ARCHIVED` was a false DENY on the wrong
+ * record and `GET /owners/%41RCHIVED` a false ALLOW on that same record. A
+ * record id is a VALUE, not a literal route segment, and express's
+ * `case sensitive routing` governs literal segments only. Compare
+ * `context.recordId` AS IT ARRIVES: do not case-fold it, do not decode it, do
+ * not derive it from `request.path`. `AccessContext.recordId` in
+ * ./types/orm-types.ts is the contract and says "Do NOT case-fold it"; the same
+ * published tarball ships both files, and THIS paragraph is the one that is
+ * wrong. Retiring it WITH its measurement is abofs/stonyx-orm#238.
  *
  * `?? ''` 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.
+ * array -- a total grant. An input you cannot identify must DENY, and that
+ * applies to BOTH arguments: since #202 the guard and the read can sit on
+ * different objects, and a guard on argument two does not protect a read of
+ * argument one. The sample returns `false` for an absent `model` AND for an
+ * absent or non-string `request.path`, rather than falling through either way.
+ *
+ * SUPERSEDED 2026-09-01 BY abofs/stonyx-orm#236/#237 as to WHAT is guarded --
+ * the principle is unchanged. The sample no longer reads `request.path`, so it
+ * returns `false` for an absent `model` AND for an absent `recordId`
+ * (`undefined`, the one spelling `auth()` never produces). Retirement of this
+ * wording: abofs/stonyx-orm#238.
  *
- * 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.
@@ -1234,10 +1317,53 @@ export default class OrmRequest extends Request {
         // src/types/orm-types.ts. Nothing is fetched at this point and adding a
         // lookup here would put a store read in the middle of an authorization
         // path. The function return shape below IS the per-record hook.
+        //
+        // -------------------------------------------------------------------------
+        // #236 -- `recordId`, the DECODED route-parameter id, for the same reason.
+        //
+        // WHICH RECORD is the third structural fact the framework already holds and
+        // the consumer was left to re-derive, and re-deriving it failed OPEN. The
+        // documented sample compared `request.path` -- the RAW, undecoded pathname
+        // -- against a literal `/archived`, while the router DECODES `:id`. So
+        // `GET /owners/%61rchived` walked past the deny and was dispatched as the
+        // record `archived`: 200 with the record in full, and DELETE answered 204
+        // with the record destroyed, unauthenticated. Four spellings measured, all
+        // four through; 255 non-canonical spellings of that 8-character id decode
+        // to the same key, so this was never a deny-list of one.
+        //
+        // TWO CONSUMER-SIDE NORMALISATIONS WERE MEASURED WRONG IN OPPOSITE
+        // DIRECTIONS, which is the argument for doing it once, here.
+        // `.toLowerCase()` case-folds a route-parameter VALUE on the axis that
+        // governs literal SEGMENTS: with a distinct owner seeded at `ARCHIVED`,
+        // `GET /owners/ARCHIVED` was a false DENY on the wrong record and
+        // `GET /owners/%41RCHIVED` a false ALLOW on that same one.
+        // `decodeURIComponent(request.path)` decodes THEN splits while the router
+        // splits THEN decodes, so it over-denied `/owners/archived%2fx` -- 403 for
+        // a genuinely distinct record. Failing closed there was luck, not design.
+        //
+        // `getId(request.params)` AND NOT `request.params.id`, for exactly the
+        // reason `operation` is a `methodAccessMap` lookup: it is the SAME single
+        // coercion the store lookup one layer down performs, so the predicate and
+        // the dispatch cannot disagree about which record a request addresses.
+        // The raw string would reintroduce that divergence on hex-shaped ids --
+        // `GET /animals/0x2391` looks up record `9105`.
+        //
+        // NOTHING HERE PARSES THE REQUEST TARGET EITHER. `request.params` is what
+        // the router matched, so a mount prefix, an absolute-form target, a query
+        // string or a case-varied mount cannot move this value -- the same
+        // guarantee `model` carries, by the same means.
+        //
+        // `null` and not `undefined` on a collection route, so the KEY IS ALWAYS
+        // PRESENT -- the rule `operation`'s own docblock already establishes. A
+        // context reaching a predicate WITHOUT the key therefore did not come from
+        // here; it was hand-assembled by a caller resolving the predicate through
+        // `Orm.instance.getAccess()`, and that absence stays deniable only because
+        // `auth()` never produces it.
         // -------------------------------------------------------------------------
         const context = {
             model: this.model,
             operation: methodAccessMap[request.method],
+            recordId: request.params && 'id' in request.params ? getId(request.params) : null,
         };
         let access;
         try {

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

@@ -242,6 +242,101 @@ export interface AccessContext {
      * 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, NOT WHICH SURFACE. `GET /owners/gina`,
+     * `GET /owners/gina/pets` and `GET /owners/gina/relationships/pets` all
+     * carry `recordId: 'gina'`; the related-resource gap is abofs/stonyx-orm#196
+     * and is untouched by this key.
+     */
+    recordId: string | number | null;
 }
 /**
  * A consumer `access()` predicate.

package/package.json

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

package/src/hooks.ts

@@ -37,7 +37,21 @@ export interface HookContext {
   state?: Record<string, unknown>;
   /** Previous record state (available in update hooks). */
   oldState?: unknown;
-  /** Target record ID for single-record operations. */
+  /**
+   * Target record ID for single-record operations.
+   *
+   * SET ONLY UNDER `delete`. `_withHooks` assigns this key in the two
+   * `operation === 'delete'` branches and nowhere else, so on `get`, `list`,
+   * `create` and `update` the key is ABSENT -- not `undefined`-valued, absent.
+   * A hook rule written as `ctx.recordId === '<id>'` never fires on an update;
+   * the addressed id is in `ctx.params`. Tracked as abofs/stonyx-orm#242.
+   *
+   * @see AccessContext.recordId in ./types/orm-types.ts -- an identically-named
+   * key on an identically-shaped context object, and NOT interchangeable with
+   * this one: it is present on every route `auth()` classifies, and spells
+   * absence as `null` rather than `undefined`. They differ in coverage on four
+   * of five operations, not only in the absence spelling.
+   */
   recordId?: string | number;
   /** Response data (available in after hooks). */
   response?: unknown;

package/src/orm-request.ts

@@ -69,6 +69,15 @@
  * records under `model: 'owner'`, and the context gives no signal of that
  * (abofs/stonyx-orm#196).
  *
+ * SUPERSEDED 2026-09-01 BY abofs/stonyx-orm#236/#237, AND KEPT FOR THE
+ * CONSTRAINT IT STATES RATHER THAN AS A DESCRIPTION OF THE CODE. The context
+ * now also carries `recordId` -- the DECODED route-parameter id, see
+ * `AccessContext.recordId` in ./types/orm-types.ts -- so the fixture's
+ * `/archived` deny IS expressible from the context alone, and the shipped
+ * sample no longer reads `request.path` at all. Retiring this wording WITH the
+ * measurement that retires it, rather than by deletion, is
+ * abofs/stonyx-orm#238.
+ *
  * `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
@@ -98,8 +107,8 @@
  *
  * 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:
+ * Measured against an ARITY-1 predicate, 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'
@@ -110,23 +119,30 @@
  * `['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.)
+ * its collection from the request. (Asserted on a live dispatch by AC9 in
+ * test/integration/orm-test.ts, against a deliberately arity-1 predicate.)
  *
- * 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.
+ * This repo's own sample access class has since been MIGRATED to read the
+ * context (abofs/stonyx-orm#222), so `getAccess('animal')` here now answers
+ * with the animal filter. That is not true of a consumer tree: an arity-1
+ * predicate keeps working -- the second argument is additive -- and the caller
+ * has no supported way to tell which kind it got. The boot-time arity warning
+ * that surfaces one is abofs/stonyx-orm#221.
  * 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:
+ * You do not have to. `auth()` below hands your predicate the ACCESS CONTEXT as
+ * argument two, and `context.model` already names the collection -- see the
+ * contract section above. Argument ONE is still the raw transport artifact, and
+ * everything from here to the end of this banner is the record of what happened
+ * when predicates worked the collection out from it. IT IS HISTORY, NOT
+ * GUIDANCE: do not write any of it into a new predicate. Every attempt to
+ * identify the collection 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.
@@ -145,22 +161,89 @@
  *      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:
+ * The fix is not a sixth rule, and it is not a better string to match. It is to
+ * stop identifying the collection at all: read `context.model`. That is a claim
+ * about IDENTIFYING THE COLLECTION, not about the sample as a whole -- the
+ * `/archived` SUB-PATH rule is still a string match, and abofs/stonyx-orm#228 is
+ * a sixth spelling that gets past it.
+ *
+ * SUPERSEDED 2026-09-01 BY abofs/stonyx-orm#236/#237: the `/archived` rule is
+ * no longer a string match against the request target -- it compares the
+ * decoded `recordId` the framework supplies -- and abofs/stonyx-orm#228 is
+ * CLOSED. Retirement of this wording: abofs/stonyx-orm#238.
+ *
+ *   An intermediate revision of the sample read `request.baseUrl` -- the mount
+ *   Express ACTUALLY MATCHED. That closed all five variants (no query string,
+ *   not mount-relative, unaffected by absolute-form, already carrying the
+ *   configured `ORM_REST_ROUTE` prefix), but it was a transport artifact
+ *   standing in for a structural fact and the sample no longer does it.
+ *   `context.model` IS the structural fact, so variants 1, 2, 4 and 5 are
+ *   unconstructible against a migrated predicate rather than handled.
+ *
+ *   VARIANT 3 SURVIVES, and is deliberately not in that list. It is the general
+ *   shape "a hand-written matcher normalises differently from the router", and a
+ *   migrated predicate still runs one string comparison for any SUB-PATH rule --
+ *   in the shipped sample, the `/archived` deny. That comparison folds case but
+ *   does not decode, so `GET /owners/%61rchived` steps past it. See the
+ *   normalisation paragraph below and abofs/stonyx-orm#228.
+ *
+ *   SUPERSEDED 2026-09-01 BY abofs/stonyx-orm#236/#237. Variant 3 lived in that
+ *   one string comparison, and the comparison is gone: the sample compares the
+ *   decoded `recordId`. Left standing rather than edited because the same
+ *   "variant 3 survives" wording sits at four sites -- this header, README.md
+ *   twice, and test/sample/access/global-access.ts -- three of which SHIP, so
+ *   retiring one of four leaves the shipped copies contradicting each other.
+ *   Retiring all four WITH their measurement is abofs/stonyx-orm#238.
+ *
+ * ONE READ OF ARGUMENT ONE SURVIVES, AND IT MUST: `request.path`. It is
+ * mount-relative and query-free, and it is for rules that distinguish SUB-PATHS
+ * beneath the mount. The context names which model and which verb, NOT which
+ * route, so the sample's `/archived` deny cannot be expressed from the context
+ * alone and a context-ONLY rewrite would silently turn that deny into an allow.
+ *
+ * SUPERSEDED 2026-09-01 BY abofs/stonyx-orm#236/#237: NO read of argument one
+ * survives in the shipped sample. `recordId` names WHICH RECORD the route was
+ * addressed to, so the `/archived` deny is expressible from the context alone
+ * -- and it still must not be dropped; expressible is not optional. Retirement
+ * of this wording: abofs/stonyx-orm#238.
+ *
+ * NORMALISE THE WAY THE ROUTER DOES, AND CASE-FOLDING ALONE IS NOT THAT. The
+ * sample lower-cases before comparing, because a matcher stricter than the
+ * case-insensitive router can be stepped around. That closes the case gap only.
+ * Express sets `request.path` from the RAW, UNDECODED pathname while the router
+ * DECODES `:id`, so `GET /owners/%61rchived` reaches a `path === '/archived'`
+ * comparison as `/%61rchived` and walks past the deny. That gap is live in the
+ * sample and is tracked as abofs/stonyx-orm#228; the `.toLowerCase()` is not a
+ * complete normalisation recipe. Compare record ids at their real case.
  *
- *   `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.
+ * DO NOT FOLLOW THE PARAGRAPH ABOVE. SUPERSEDED 2026-09-01 BY
+ * abofs/stonyx-orm#236/#237, and flagged here rather than merely dated because
+ * it is an INSTRUCTION, not a stale observation. `.toLowerCase()` on the access
+ * path was measured WRONG IN BOTH DIRECTIONS AT ONCE: with a distinct owner
+ * seeded at `ARCHIVED`, `GET /owners/ARCHIVED` was a false DENY on the wrong
+ * record and `GET /owners/%41RCHIVED` a false ALLOW on that same record. A
+ * record id is a VALUE, not a literal route segment, and express's
+ * `case sensitive routing` governs literal segments only. Compare
+ * `context.recordId` AS IT ARRIVES: do not case-fold it, do not decode it, do
+ * not derive it from `request.path`. `AccessContext.recordId` in
+ * ./types/orm-types.ts is the contract and says "Do NOT case-fold it"; the same
+ * published tarball ships both files, and THIS paragraph is the one that is
+ * wrong. Retiring it WITH its measurement is abofs/stonyx-orm#238.
  *
  * `?? ''` 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.
+ * array -- a total grant. An input you cannot identify must DENY, and that
+ * applies to BOTH arguments: since #202 the guard and the read can sit on
+ * different objects, and a guard on argument two does not protect a read of
+ * argument one. The sample returns `false` for an absent `model` AND for an
+ * absent or non-string `request.path`, rather than falling through either way.
+ *
+ * SUPERSEDED 2026-09-01 BY abofs/stonyx-orm#236/#237 as to WHAT is guarded --
+ * the principle is unchanged. The sample no longer reads `request.path`, so it
+ * returns `false` for an absent `model` AND for an absent `recordId`
+ * (`undefined`, the one spelling `auth()` never produces). Retirement of this
+ * wording: abofs/stonyx-orm#238.
  *
- * 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.
@@ -1354,10 +1437,53 @@ export default class OrmRequest extends Request {
     // src/types/orm-types.ts. Nothing is fetched at this point and adding a
     // lookup here would put a store read in the middle of an authorization
     // path. The function return shape below IS the per-record hook.
+    //
+    // -------------------------------------------------------------------------
+    // #236 -- `recordId`, the DECODED route-parameter id, for the same reason.
+    //
+    // WHICH RECORD is the third structural fact the framework already holds and
+    // the consumer was left to re-derive, and re-deriving it failed OPEN. The
+    // documented sample compared `request.path` -- the RAW, undecoded pathname
+    // -- against a literal `/archived`, while the router DECODES `:id`. So
+    // `GET /owners/%61rchived` walked past the deny and was dispatched as the
+    // record `archived`: 200 with the record in full, and DELETE answered 204
+    // with the record destroyed, unauthenticated. Four spellings measured, all
+    // four through; 255 non-canonical spellings of that 8-character id decode
+    // to the same key, so this was never a deny-list of one.
+    //
+    // TWO CONSUMER-SIDE NORMALISATIONS WERE MEASURED WRONG IN OPPOSITE
+    // DIRECTIONS, which is the argument for doing it once, here.
+    // `.toLowerCase()` case-folds a route-parameter VALUE on the axis that
+    // governs literal SEGMENTS: with a distinct owner seeded at `ARCHIVED`,
+    // `GET /owners/ARCHIVED` was a false DENY on the wrong record and
+    // `GET /owners/%41RCHIVED` a false ALLOW on that same one.
+    // `decodeURIComponent(request.path)` decodes THEN splits while the router
+    // splits THEN decodes, so it over-denied `/owners/archived%2fx` -- 403 for
+    // a genuinely distinct record. Failing closed there was luck, not design.
+    //
+    // `getId(request.params)` AND NOT `request.params.id`, for exactly the
+    // reason `operation` is a `methodAccessMap` lookup: it is the SAME single
+    // coercion the store lookup one layer down performs, so the predicate and
+    // the dispatch cannot disagree about which record a request addresses.
+    // The raw string would reintroduce that divergence on hex-shaped ids --
+    // `GET /animals/0x2391` looks up record `9105`.
+    //
+    // NOTHING HERE PARSES THE REQUEST TARGET EITHER. `request.params` is what
+    // the router matched, so a mount prefix, an absolute-form target, a query
+    // string or a case-varied mount cannot move this value -- the same
+    // guarantee `model` carries, by the same means.
+    //
+    // `null` and not `undefined` on a collection route, so the KEY IS ALWAYS
+    // PRESENT -- the rule `operation`'s own docblock already establishes. A
+    // context reaching a predicate WITHOUT the key therefore did not come from
+    // here; it was hand-assembled by a caller resolving the predicate through
+    // `Orm.instance.getAccess()`, and that absence stays deniable only because
+    // `auth()` never produces it.
     // -------------------------------------------------------------------------
     const context: AccessContext = {
       model: this.model,
       operation: methodAccessMap[request.method],
+      recordId: request.params && 'id' in request.params ? getId(request.params) : null,
     };
 
     let access: AccessMethod;