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

package/README.md

@@ -315,15 +315,49 @@ Access classes define models and provide custom filtering/authorization logic.
 > [Identifying the collection](#identifying-the-collection) before copying this.**
 > Every attempt to identify the collection by parsing the request target has
 > failed **open** — five distinct variants of this same example, each found only
-> after the previous was fixed, by five different people. The sample below does
-> not parse anything: it reads `request.baseUrl`, the mount Express actually
-> matched.
+> after the previous was fixed, by five different people. That section is now a
+> record of what not to do, not a matching recipe: the sample below reads `model`
+> from [the access context](#the-access-context-second-argument) and never looks
+> at the mount at all, so variants 1, 2, 4 and 5 are **unconstructible** against
+> it rather than merely handled. **Variant 3 survives.** It is the general shape
+> "a hand-written matcher normalises differently from the router", and the
+> migrated sample still runs one string comparison — the `/archived` sub-path
+> deny — which folds case but does not decode, so `GET /owners/%61rchived` steps
+> past it ([#228](https://github.com/abofs/stonyx-orm/issues/228)).
+>
+> **Superseded 2026-09-01 by [#236](https://github.com/abofs/stonyx-orm/issues/236) /
+> [#237](https://github.com/abofs/stonyx-orm/issues/237), and left standing rather
+> than rewritten.** Both claims above are now false: `#228` is **closed**, and the
+> one string comparison variant 3 lived in is gone — the sample below compares the
+> **decoded `recordId`** the access context supplies, so there is no comparison
+> left to step around. The paragraph about `request.path` further down is
+> superseded the same way. Nothing here is deleted because the same "variant 3
+> survives" wording sits at four sites (this file twice, `src/orm-request.ts`, and
+> the test fixture) and retiring one of four leaves the shipped copies
+> contradicting each other; retiring all four **with the measurement that retires
+> them** is [#238](https://github.com/abofs/stonyx-orm/issues/238), which also owns
+> this blockquote and the reference section below.
 >
 > That is still a stopgap. **The real fix is
 > [#202](https://github.com/abofs/stonyx-orm/issues/202)** — `access()` should
 > receive the model, the operation and the record, so there is nothing to
 > identify. Until it lands, prefer the array shape (`['read']`) or `false` where
 > you can: the **function** shape is the one that requires any matching at all.
+>
+> The one read of argument **one** that survives is `request.path`, for the
+> `/archived` sub-path deny — and it has to. The context names which model and
+> which verb, not which route, so that deny **cannot be expressed from the
+> context alone** and a context-only rewrite would silently turn it into an
+> allow.
+>
+> **Superseded 2026-09-01 by [#236](https://github.com/abofs/stonyx-orm/issues/236) /
+> [#237](https://github.com/abofs/stonyx-orm/issues/237)** — see the dated note
+> above. No read of argument **one** survives in the sample below: the context
+> carries `recordId`, the decoded route-parameter id, so the `/archived` deny **is**
+> expressible from the context alone. It still must not be dropped — expressible is
+> not optional. Retirement of this wording:
+> [#238](https://github.com/abofs/stonyx-orm/issues/238).
+>
 > The same warning is repeated at the top of `src/orm-request.ts`, which ships;
 > the longer write-up in `docs/usage-patterns.md` does **not** ship, so this
 > README and that source header are the two copies a consumer sees.
@@ -337,28 +371,73 @@ Access classes define models and provide custom filtering/authorization logic.
 export default class GlobalAccess {
   models = ['owner', 'animal'];
 
-  access(request) {
-    // `request.baseUrl` is the mount Express matched — `/owners`, or
-    // `/api/owners` under ORM_REST_ROUTE=/api. Never parse `originalUrl`: it is
-    // the raw request target and can be absolute-form.
-    const mount = request.baseUrl;
-
-    // FAIL CLOSED. If Express did not tell us what it matched we are not behind
-    // the mount we think we are, and an unidentifiable request denies rather
-    // than falling through to the CRUD grant at the bottom.
-    if (typeof mount !== 'string' || mount === '') return false;
-
-    // Lower-cased because the router matched case-INSENSITIVELY, and a matcher
-    // stricter than the router that dispatched the request can be stepped
-    // around. The PATH only — record ids stay at their real case below.
-    const collection = mount.toLowerCase();
-
-    // `request.path` is mount-relative and query-free, so sub-path rules need no
-    // prefix arithmetic either. false → 403 for the whole request.
-    const path = String(request.path ?? '').toLowerCase();
-
-    if (collection.endsWith('/owners')) {
-      if (path === '/archived' || path.startsWith('/archived/')) return false;
+  access(request, { model, operation, recordId }) {
+    // `model` is the model this route was mounted for. It is assigned once, at
+    // mount time, and no request can influence it — not a mount prefix, not a
+    // query string, not a case-varied path, not an absolute-form request
+    // target. `recordId` is the record this route was ADDRESSED TO, decoded by
+    // the router and coerced to the key the store lookup uses. Nothing below
+    // parses anything, and since abofs/stonyx-orm#236 nothing below reads
+    // argument one AT ALL. Variants 1, 2, 4 and 5 were already unconstructible;
+    // the sub-path STRING COMPARISON that variant 3 lived in is gone too,
+    // replaced by a comparison against the decoded id. Retiring the "variant 3
+    // survives" wording at the four sites that still carry it — with the
+    // measurement that retires it, rather than by deletion — is
+    // abofs/stonyx-orm#238.
+    //
+    // `operation` is destructured to name the whole contract at the point of
+    // use. This sample's rules are per-model and per-record rather than
+    // per-verb, so it does not branch on it; the permission array at the bottom
+    // is where the verb is answered.
+
+    // FAIL CLOSED ON AN UNIDENTIFIABLE MODEL. `model` is absent for any caller
+    // that resolved this predicate without supplying the context, and a request
+    // this function cannot identify DENIES rather than falling through to the
+    // CRUD grant at the bottom. An unidentifiable input must never be the
+    // permissive path.
+    if (typeof model !== 'string' || model === '') return false;
+
+    if (model === 'owner') {
+      // FAIL CLOSED ON AN ABSENT `recordId` TOO, AND `undefined` IS THE ONLY
+      // SPELLING OF ABSENT. `auth()` ALWAYS sets the key — `null` on a
+      // collection route, which is addressed to no record — so `undefined`
+      // means the context did not come from `auth()`: it was hand-assembled by
+      // a caller resolving this predicate through the documented
+      // `Orm.instance.getAccess()` path. Letting that through would fall
+      // straight to the per-record filter below, which is a DENY becoming an
+      // ALLOW. This is the same rule the old guard on `request.path` enforced,
+      // moved to the argument this predicate now actually reads.
+      if (recordId === undefined) return false;
+
+      // THE `/archived` DENY, EXPRESSED AGAINST THE DECODED ID. It used to be
+      // `request.path.toLowerCase()` compared against `'/archived'`, and that
+      // was wrong in both directions at once.
+      //
+      // TOO PERMISSIVE: express sets `request.path` from the RAW pathname while
+      // the router DECODES `:id`, so `GET /owners/%61rchived` reached the
+      // comparison as `/%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. 255
+      // non-canonical spellings of that 8-character id decode to the same key,
+      // so no deny-list of spellings was ever going to close it.
+      //
+      // TOO STRICT: 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`, the `.toLowerCase()` 403'd
+      // `GET /owners/ARCHIVED` — the wrong record — while still admitting
+      // `GET /owners/%41RCHIVED`, the same record encoded.
+      //
+      // SO DO NOT NORMALISE `recordId`. It is already decoded, exactly ONCE,
+      // which is what a route parameter means: `/owners/%2561rchived` is the
+      // legitimate id `%61rchived`, and decoding until stable would deny it. Do
+      // not case-fold it. Do not rebuild it from `request.path` — decoding the
+      // whole path decodes THEN splits while the router splits THEN decodes,
+      // which over-denies the distinct record at `/owners/archived%2fx`.
+      //
+      // THE DENY IS NOW EXPRESSIBLE FROM THE CONTEXT ALONE, which is exactly
+      // what `recordId` bought — and it still must not be dropped. Deleting it
+      // does not remove a rule loudly, it turns a deny into an ALLOW, silently.
+      if (recordId === 'archived') return false;
 
       // Returning a function plugs it in as a per-record filter, and it is
       // enforced on every surface addressed to one of these records:
@@ -373,7 +452,7 @@ export default class GlobalAccess {
     // inert. Deliberately NO `?? record.owner` fallback: accepting the raw
     // shape as well as the resolved one would absorb a resolution regression
     // silently, which is exactly what blinded this fixture before.
-    if (collection.endsWith('/animals')) return record => record.owner?.id !== 'restricted';
+    if (model === 'animal') return record => record.owner?.id !== 'restricted';
 
     // Allows full access to all calls that don't match any of the above conditions
     return ['read', 'create', 'update', 'delete'];
@@ -441,6 +520,16 @@ access class shipped with this repo has such a rule: its `/archived` deny
 **cannot be expressed from the context alone**, and a predicate migrated to
 context-only would silently drop it — a deny becoming an allow.
 
+**Superseded 2026-09-01 by [#236](https://github.com/abofs/stonyx-orm/issues/236) /
+[#237](https://github.com/abofs/stonyx-orm/issues/237).** The context also carries
+`recordId` — the record this route was addressed to, already decoded — so the
+`/archived` deny **is** expressible from the context alone, and the shipped sample
+no longer reads `request.path`. The full contract is `AccessContext.recordId` in
+`src/types/orm-types.ts`, which ships. This section — the signature, the key table
+and this paragraph — is corrected by
+[#238](https://github.com/abofs/stonyx-orm/issues/238); the pointer is here because
+what it currently says is an instruction, and the instruction is wrong.
+
 Note also that the related-resource and `?include=` surfaces serve *another
 model's* records under `model: 'owner'`, and the context gives a predicate no
 signal that it is authorizing a related-resource route. That is
@@ -523,9 +612,10 @@ sample, `getAccess('owner') === getAccess('animal')`.
 #### 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 the context.** Measured against the access class shipped with this
-repo, on a request Express dispatched to `GET /owners/angela`, asked about
-**animals**:
+has to read the context.** Against a predicate that ignores it the failure is
+measurable. On a request Express dispatched to `GET /owners/angela`, asked about
+**animals**, the sample as it shipped before
+[#222](https://github.com/abofs/stonyx-orm/issues/222) answered:
 
 ```
 getAccess('animal')(ownersRequest, { model: 'animal', operation: 'read' })
@@ -533,18 +623,26 @@ getAccess('animal')(ownersRequest, { model: 'animal', operation: 'read' })
 ```
 
 That is the **owners** filter, and it returns `true` for animal 21 — the record
-hidden on every animal surface. Under a mount that predicate recognizes neither
-way it is worse still: it falls through to
-`['read', 'create', 'update', 'delete']`, a full CRUD grant.
-
-Either way the context was supplied and the answer is not the animal answer, and
-it is wrong in the direction that **grants**. That predicate is single-argument
-and identifies its collection from the request, so it answered about the
-collection the request is *addressed to* while being asked about another one.
-Every predicate in this repo, and in every consumer tree, is single-argument on
-the day this ships, and a caller has no supported way to tell which kind it
-resolved. The boot-time arity warning that would surface it is
-[#213](https://github.com/abofs/stonyx-orm/issues/213).
+hidden on every animal surface. Under a mount such a predicate recognizes
+neither way it is worse still: it falls through to
+`['read', 'create', 'update', 'delete']`, a full CRUD grant. Either way the
+context was supplied and the answer is not the animal answer, and it is wrong in
+the direction that **grants** — because that predicate was single-argument and
+identified its collection from the request, so it answered about the collection
+the request was *addressed to* while being asked about another one.
+
+The sample shipped with this repo has since been migrated to read the context,
+and the same call now answers with the **animal** filter:
+
+```
+getAccess('animal')(ownersRequest, { model: 'animal', operation: 'read' })
+  ->  record => record.owner?.id !== 'restricted'
+```
+
+A single-argument predicate remains the default in every consumer tree, and a
+caller has no supported way to tell which kind it resolved. The boot-time arity
+warning that surfaces one is
+[#221](https://github.com/abofs/stonyx-orm/issues/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 it.
@@ -676,9 +774,17 @@ no hidden records to disclose.
 
 ### Identifying the collection
 
-**Do not reconstruct the request path.** Every version of this sample that tried
-to has failed **open**, and each variant was found only after the previous one
-was fixed:
+**Do not reconstruct the request path — and since
+[#202](https://github.com/abofs/stonyx-orm/issues/202) you do not have to
+identify the collection at all.** Read `model` from
+[the access context](#the-access-context-second-argument): it is fixed at mount
+time, no request can influence it, and there is nothing left to parse.
+
+**Everything below is the record of what happened when this sample did parse
+it.** It is kept as history, not as a recipe — none of these matching strategies
+should be written into a new predicate. Every version of this sample that tried
+to identify the collection from the request target failed **open**, and each
+variant was found only after the previous one was fixed:
 
 | # | Variant | Why it fails open |
 |---|---|---|
@@ -688,13 +794,27 @@ was fixed:
 | 4 | hard-coded `/owners` | With `ORM_REST_ROUTE=/api` every url becomes `/api/owners/...` and the sample matches nothing — environment-specifically, which is harder to notice than failing everywhere. The remediation this document used to give was itself broken: `` `${config.orm.restServer.route}owners` `` evaluates to **`/apiowners`**, so a reader who followed the correction exactly still failed open and believed they had handled it. |
 | 5 | any match on `originalUrl` at all | HTTP/1.1 permits an **absolute-form** request-target. Express routes on `parseurl(req).pathname`, so the request dispatches normally — but `originalUrl` is the raw target. `GET http://anything.example/owners/angela` yields `originalUrl === 'http://anything.example/owners/angela'`, which has no `/owners` prefix. Measured: the record came back in full, `DELETE` succeeded, and it walked past a hard `return false` deny the same way. |
 
-**The fix is not a sixth rule.** It is to stop parsing:
-
-**Use `request.baseUrl`.** It is the mount Express *actually matched* when it
-dispatched the request. It carries no query string (variant 2), it is not
-mount-relative (variant 1), it already contains the configured `ORM_REST_ROUTE`
-prefix (variant 4 — there is nothing left to derive, so `/apiowners` is
-unconstructible), and it is unaffected by an absolute-form target (variant 5).
+**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. That is a statement about
+**identifying the collection**, and it is not a statement about the sample as a
+whole: the `/archived` sub-path rule *is* still a string match, and
+[#228](https://github.com/abofs/stonyx-orm/issues/228) is a sixth spelling that
+gets past it. Sub-path rules are the residue this fix does not cover, which is
+why they must normalise the way the router does.
+
+An intermediate revision read **`request.baseUrl`** — the mount Express
+*actually matched*. That closed all five variants: it carries no query string
+(variant 2), it is not mount-relative (variant 1), it already contains the
+configured `ORM_REST_ROUTE` prefix (variant 4 — there is nothing left to derive,
+so `/apiowners` is unconstructible), and it is unaffected by an absolute-form
+target (variant 5). It was still a transport artifact standing in for a
+structural fact, and it is **no longer what the sample does**: the sample reads
+`model`, so variants 1, 2, 4 and 5 are unconstructible against it rather than
+handled. **Variant 3 survives**, in the one string comparison the migration
+leaves behind: the `/archived` sub-path deny folds case but does not decode
+([#228](https://github.com/abofs/stonyx-orm/issues/228)). The table below is
+retained as the measured evidence behind the five variants, not because any of
+these values should be matched on:
 
 | request | `request.url` | `request.originalUrl` | `request.baseUrl` | `request.path` |
 |---|---|---|---|---|
@@ -705,21 +825,60 @@ unconstructible), and it is unaffected by an absolute-form target (variant 5).
 | `GET http://anything.example/owners/angela` | `http://anything.example/angela` | `http://anything.example/owners/angela` | `/owners` | `/angela` |
 | `GET /api/animals/22` (`ORM_REST_ROUTE=/api`) | `/22` | `/api/animals/22` | `/api/animals` | `/22` |
 
-Two rules remain, and they are the whole list:
-
-**1. Compare lower-cased.** `baseUrl` is the text the caller sent, not the
-registered mount — `GET /OwNeRs/angela` yields `/OwNeRs`. The router matched it
-case-insensitively, so a case-sensitive comparison here is stricter than the
-router and can be walked past. Lower-case the **mount and path only**; record ids
-are case-sensitive and must be compared at their real case.
-
-**2. Fail closed when `baseUrl` is absent.** `String(request.originalUrl ?? '')`
-was added to stop a `TypeError`, and it traded fail-closed for fail-**open**: an
-empty string matches no collection, so `access()` fell through to the permission
-array and granted full CRUD. An input you cannot identify must **deny**.
-
-Use `request.path` — mount-relative and query-free — if you need to distinguish
-sub-paths beneath the mount, as the `/archived` deny above does.
+**Superseded 2026-09-01 by [#236](https://github.com/abofs/stonyx-orm/issues/236) /
+[#237](https://github.com/abofs/stonyx-orm/issues/237) — "Variant 3 survives" above,
+and the two paragraphs below, are no longer true.** The access context now carries
+`recordId`, the **decoded** route-parameter id, and the sample compares against it:
+the one string comparison variant 3 lived in is gone, `#228` is **closed**, and no
+read of argument one survives in the sample. The wording is left standing rather
+than deleted because it appears at four sites (this file twice,
+`src/orm-request.ts`, and the test fixture) and retiring one of four leaves the
+shipped copies contradicting each other; retiring all four **with the measurement
+that retires them** is [#238](https://github.com/abofs/stonyx-orm/issues/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 — as the `/archived` deny in the sample above does. The context
+names which model and which verb, **not which route**, so that deny *cannot be
+expressed from the context alone*, and a context-only rewrite would silently turn
+it into an allow.
+
+**Normalise the way the router that dispatched the request does — and
+case-folding alone does not.** A matcher stricter than the router can be stepped
+around, so the sample lower-cases before comparing (the router matched
+case-insensitively). That closes the case gap and **it is not the whole rule**:
+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`, walks past the deny, and is dispatched as the record
+`archived`. That gap is live in the sample above and is tracked as
+[#228](https://github.com/abofs/stonyx-orm/issues/228) — **do not read the
+`.toLowerCase()` there as a complete normalisation recipe.** Record ids are
+case-sensitive and must be compared at their real case.
+
+**Do not follow the two paragraphs above — superseded 2026-09-01 by
+[#236](https://github.com/abofs/stonyx-orm/issues/236) /
+[#237](https://github.com/abofs/stonyx-orm/issues/237).** They are *instructions*,
+not merely stale observations, which is why this note is louder than a date. The
+sample no longer reads `request.path` and no longer calls `.toLowerCase()` on
+anything it compares: `.toLowerCase()` 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. Compare `recordId` **as it arrives**: do not case-fold it, do
+not decode it, do not derive it from `request.path`. The contract is
+`AccessContext.recordId` in `src/types/orm-types.ts`, which ships and says "Do NOT
+case-fold it". Retirement of this wording, with its measurement:
+[#238](https://github.com/abofs/stonyx-orm/issues/238).
+
+**Fail closed on anything you cannot identify — on *either* argument.**
+`String(request.originalUrl ?? '')` was once added here to stop a `TypeError`,
+and it traded fail-closed for fail-**open**: an empty string matched no
+collection, so `access()` fell through to the permission array and granted full
+CRUD. The same rule applies to the context — the sample returns `false` for an
+absent `model` rather than falling through. 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 therefore also returns `false` when `request.path` is
+absent or is not a string, rather than letting `?? ''` fall through to the
+per-record filter. An input you cannot identify must **deny**.
 
 ### Known limitations
 
@@ -742,11 +901,14 @@ sub-paths beneath the mount, as the `/archived` deny above does.
   see [The access context](#the-access-context-second-argument):
   `Orm.instance.getAccess(modelName)` makes another model's predicate
   **reachable**, and `context.model` makes a **model-correct answer possible** —
-  possible, not guaranteed: the resolved predicate has to read the context, and
-  every predicate in tree is still single-argument
-  ([#213](https://github.com/abofs/stonyx-orm/issues/213)), so today it answers
-  about the collection the request is addressed to. **The mechanism exists; the
-  ORM does not yet use it on this path.** The re-parenting write above is still
+  possible, not guaranteed: the resolved predicate has to read the context. The
+  sample shipped with this repo now does
+  ([#222](https://github.com/abofs/stonyx-orm/issues/222)), so
+  `getAccess('animal')` answers with the animal filter; a predicate that ignores
+  the second argument still answers about the collection the request is
+  addressed to, and the boot-time warning that surfaces one is
+  [#221](https://github.com/abofs/stonyx-orm/issues/221). **The mechanism
+  exists; the ORM does not yet use it on this path.** The re-parenting write above is still
   **not refused** — that enforcement is
   [#196](https://github.com/abofs/stonyx-orm/issues/196) and
   [#207](https://github.com/abofs/stonyx-orm/issues/207), which were blocked on
@@ -1087,6 +1249,16 @@ Each hook receives a context object with comprehensive information:
 - It contains a deep copy of the record's state **before** the operation executes (captured before the `before` hook fires)
 - The deep copy is created via JSON serialization (`JSON.parse(JSON.stringify())`) to ensure complete isolation
 - For `delete` operations, `recordId` is provided in after hooks since the record may no longer exist in the store
+- **`context.recordId` here is NOT `AccessContext.recordId`.** Same name, same-shaped
+  object, different coverage: `_withHooks` sets this key **only** under
+  `operation === 'delete'`, so on `get` / `list` / `create` / `update` the key is
+  **absent** — `beforeHook('update', 'owner', ctx => ctx.recordId === 'archived' ? 403 : undefined)`
+  never fires (measured: `PATCH /owners/{id}` → 200 with `ctx.recordId === undefined`
+  and the id sitting in `ctx.params`). The access context, by contrast, carries
+  `recordId` on every route it classifies and spells absence as `null`, never
+  `undefined`. Tracked as
+  [#242](https://github.com/abofs/stonyx-orm/issues/242); see
+  `AccessContext.recordId` in `src/types/orm-types.ts` for the other side.
 - `oldState` is captured as a deep copy of the record's data before the operation, providing access to the previous field values
 
 ### Usage Examples

package/dist/hooks.d.ts

@@ -20,7 +20,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/dist/orm-request.d.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.
  *
- *   `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.
+ * 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.
+ *
+ * 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.