@stonyx/orm 0.3.2-alpha.72 → 0.3.2-alpha.74

package/README.md

@@ -325,6 +325,19 @@ Access classes define models and provide custom filtering/authorization logic.
 > 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
@@ -337,6 +350,14 @@ Access classes define models and provide custom filtering/authorization logic.
 > 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.
@@ -350,66 +371,73 @@ Access classes define models and provide custom filtering/authorization logic.
 export default class GlobalAccess {
   models = ['owner', 'animal'];
 
-  access(request, { model, operation }) {
+  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. Nothing below parses anything, so variants 1, 2, 4 and 5 are not
-    // constructible against this predicate any more — they are history, not
-    // rules to follow. VARIANT 3 IS THE EXCEPTION AND THE CLAIM IS NARROWER
-    // THAN IT WAS: a matcher stricter than the router can still be stepped
-    // around, because the sub-path rule below is still a string comparison.
-    // Case is handled; percent-encoding is not — abofs/stonyx-orm#228.
+    // 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-sub-path rather than
+    // 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 ARGUMENT TWO. `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. Argument ONE is guarded at its own read, below — this guard does
-    // not cover it.
+    // 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') {
-      // The context names WHICH MODEL and WHICH VERB — not which route. Six
-      // distinct owner surfaces produce one identical context, so a rule that
-      // depends on the SUB-PATH still needs argument one. `request.path` is
-      // mount-relative and query-free, and it is the one read of the raw
-      // request the README sanctions. false → 403 for the whole request.
+      // 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.
       //
-      // THIS DENY CANNOT BE EXPRESSED FROM THE CONTEXT ALONE. Migrating it away
-      // does not remove a rule, it turns a deny into an ALLOW, silently.
+      // 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.
       //
-      // FAIL CLOSED ON ARGUMENT ONE TOO. The guard above covers the context;
-      // this one covers the request, and since #202 they are two different
-      // objects. A caller that resolves this predicate through the documented
-      // `Orm.instance.getAccess()` path and hand-assembles a request can supply
-      // a perfectly valid context with no usable `path` — and
-      // `String(request.path ?? '')` is then `''`, which matches no sub-path
-      // rule and falls straight through to the per-record filter below. That is
-      // a DENY becoming an ALLOW. An input this function cannot identify DENIES,
-      // whichever ARGUMENT it arrived on — which is also why the `?? ''` this
-      // file's header condemns does not appear below.
-      if (typeof request?.path !== 'string' || request.path === '') return false;
-
-      // Lower-cased because the router matched case-insensitively, so a
-      // case-sensitive rule here would be stricter than the router and could be
-      // stepped around.
+      // 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.
       //
-      // CASE-FOLDING ALONE IS NOT A SUFFICIENT NORMALISATION, and this line is
-      // not a recipe for one. Express sets `request.path` from the RAW pathname
-      // while the router DECODES `:id`, so `GET /owners/%61rchived` reaches this
-      // comparison as `/%61rchived`, walks past the deny, and is dispatched as
-      // the record `archived` — abofs/stonyx-orm#228. A matcher must normalise
-      // the way the router that dispatched the request does. Record ids are
-      // case-sensitive and must be compared at their real case.
-      const path = request.path.toLowerCase();
-
-      if (path === '/archived' || path.startsWith('/archived/')) return false;
+      // 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:
@@ -492,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
@@ -787,6 +825,17 @@ these values should be matched on:
 | `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` |
 
+**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
@@ -806,6 +855,20 @@ comparison as `/%61rchived`, walks past the deny, and is dispatched as the recor
 `.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
@@ -867,20 +930,36 @@ per-record filter. An input you cannot identify must **deny**.
   `include=`, related-resource routes and relationship-linkage routes. This is
   **membership** — whether the related resource is served at all — and it is a
   different question from which ids a document may *name*, immediately below.
-- **Relationship linkage is filtered on the four request-bound read surfaces,
-  and only there.** A document's `relationships.*.data` used to publish the id
-  of every related record unconditionally, so a record hidden on every one of
-  its own surfaces was still named inside another model's document — with no
-  `include=`, no relationship route and no query string
+- **Relationship linkage is filtered on every request-bound surface that
+  serializes a record — the reads, the two writes, and `included`.** A
+  document's `relationships.*.data` used to publish the id of every related
+  record unconditionally, so a record hidden on every one of its own surfaces
+  was still named inside another model's document — with no `include=`, no
+  relationship route and no query string
   ([#234](https://github.com/abofs/stonyx-orm/issues/234)). The ORM now resolves
-  the **related** model's own access class on `GET /:models`, `GET /:models/:id`
-  and both `GET /:models/:id/{relationship}` shapes, and asks it
-  `{ model: <related>, operation: 'read' }`. An unresolvable class
+  the **related** model's own access class on `GET /:models`, `GET /:models/:id`,
+  both `GET /:models/:id/{relationship}` shapes, the `POST /:models` and
+  `PATCH /:models/:id` **response documents**, and every record inside an
+  `?include=` **`included`** array
+  ([#235](https://github.com/abofs/stonyx-orm/issues/235)), and asks it
+  `{ model: <related>, operation: 'read' }`. **`operation` is `'read'` even on a
+  write route, and that is correct rather than an oversight** — the question
+  asked of the *related* model is "may this caller **read** this id", not "may
+  they update it". An access class that grants `['create']` but not `['read']`
+  on the related model therefore denies that linkage on its own `POST`
+  response; that is the fail-closed direction. Do **not** wire these handlers to
+  `methodAccessMap[request.method]`: it would ask a different question on a
+  write route than on a read route, which is the two-vocabularies failure
+  `createLinkageFilter` exists to prevent. An unresolvable class
   (`getAccess()` → `undefined`) and a predicate that throws both **deny**. A
   filtered-out relationship is **indistinguishable from a genuinely empty one** —
   an emptied `hasMany` is `data: []` and an emptied `belongsTo` is `data: null`,
   both **keeping their `links`**, which are built from the serialized record's
-  own id and never from the related one. Nothing errors and no status changes,
+  own id and never from the related one. On the two **write** surfaces there are
+  no `links` to keep: neither handler passes a `baseUrl`, so a filtered and a
+  genuinely-empty relationship are both a bare `{ "data": … }` there. That is
+  pre-existing and deliberate — adding `baseUrl` to the write handlers would be
+  an unrelated change to their response shape. Nothing errors and no status changes,
   because throwing here would be an existence oracle *and* would throw out of
   the enclosing `JSON.stringify`.
 
@@ -907,28 +986,32 @@ per-record filter. An input you cannot identify must **deny**.
   **Not yet covered, and each one still publishes ids the surfaces above
   withhold:**
 
-  - **`included`** — [#235](https://github.com/abofs/stonyx-orm/issues/235). A
-    permitted record sideloaded by `?include=` emits its **own**
-    `relationships.*.data` unfiltered, so `GET /animals/1?include=owner,owner.pets`
-    returns `owner.data: null` on the primary document and then names angela in
-    `included`, along with eight permitted animals that each name
-    `{"type":"owner","id":"angela"}`. Separately,
-    [#233](https://github.com/abofs/stonyx-orm/issues/233) owns whether a
-    resource appears in `included` **at all** — that is membership, a different
-    question, and following it will not lead you to this residual.
-  - **The `POST`/`PATCH` response documents** —
-    [#235](https://github.com/abofs/stonyx-orm/issues/235). `createHandler` and
-    `updateHandler` destructure the request rather than binding it, so wiring
-    them needs a signature change rather than an argument. Until then **one HTTP
-    verb defeats the filter on the same record**: measured, `GET /animals/1`
-    returns `owner.data: null` and `PATCH /animals/1` returns **200 naming
-    angela**, seconds apart, with no query string and no relationship route. Any
-    caller who can read a record can also write it and be handed the id the read
-    withheld.
   - **`GET /:models/:id/relationships/{relationship}`**, whose *primary data* is
     linkage, so filtering it is a **membership** decision —
     [#232](https://github.com/abofs/stonyx-orm/issues/232), the filed child of
-    [#196](https://github.com/abofs/stonyx-orm/issues/196).
+    [#196](https://github.com/abofs/stonyx-orm/issues/196). This route builds
+    its `{type, id}` objects by hand and never calls `toJSON`, so it does not
+    see a `linkage` option no matter who supplies one. Measured:
+    `GET /animals/1/relationships/owner` answers
+    `{"type":"owner","id":"angela"}` while `GET /owners/angela` is `404`.
+  - **Whether a related resource appears in `included` at all** —
+    [#233](https://github.com/abofs/stonyx-orm/issues/233). #235 filters what a
+    record *already in* `included` may **name**; a hidden record is still a
+    **member** of that array. The two are different questions and neither closes
+    the other: after #235, `GET /animals/1?include=owner,owner.pets` returns
+    `owner.data: null` on every permitted animal it sideloads **and still
+    includes the hidden owner as a resource**.
+  - **A computed attribute that interpolates a related record's id.** This is a
+    **consumer-side** residual and the ORM cannot close it. `relationships.*.data`
+    is a structure this module builds, so it can be filtered; a computed
+    property is arbitrary consumer code returning an arbitrary value, and
+    deciding which substrings of it are identifiers is not something the
+    framework can do. Measured on this repo's own fixture, where the `animal`
+    model has a `get tag()` that interpolates `owner.id`: **every** animal
+    document on **every** surface — including the ones above — carries
+    `attributes.tag: "angela's small dog"` for an owner that answers `404`. If
+    your access rules hide a record, audit your computed properties for its
+    identifiers.
 - **A bare `toJSON()` still emits unfiltered linkage, and that is deliberate.**
   `Record.toJSON()` **applies** a verdict; it never **resolves** one. It has no
   request, and the documented `access()` contract permits a predicate to read
@@ -1326,13 +1409,15 @@ GET /animals/1
 #### Limitations
 
 - Only available on GET endpoints (not POST/PATCH)
-- **`included` records are not access-filtered, on either question.** Whether a
-  resource appears in `included` at all is
-  [#233](https://github.com/abofs/stonyx-orm/issues/233); a record that *is*
-  permitted still emits its **own** `relationships.*.data` unfiltered, so
-  `?include=` republishes ids the primary document withholds
-  ([#235](https://github.com/abofs/stonyx-orm/issues/235)). See
-  [Consumer Contracts](#consumer-contracts).
+- **`included` is access-filtered on one of the two questions, not both.** What
+  a record already in `included` may **name** in its own
+  `relationships.*.data` is filtered
+  ([#235](https://github.com/abofs/stonyx-orm/issues/235)) — `?include=` no
+  longer republishes ids the primary document withholds. Whether a resource
+  appears in `included` **at all** is *membership* and is still unfiltered
+  ([#233](https://github.com/abofs/stonyx-orm/issues/233)): a record that is
+  404 on its own routes is still served as an `included` resource, attributes
+  and all. See [Consumer Contracts](#consumer-contracts).
 
 ## Lifecycle Hooks
 
@@ -1387,6 +1472,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/access-verdict.js

@@ -144,7 +144,37 @@ function resolveVerdict(request, type) {
         return DENIED;
     let access;
     try {
-        access = predicate(request, { model: type, operation: 'read' });
+        // `recordId: null`, AND NOT `request.params.id`. THE TEMPTING WRONG ANSWER
+        // IS RIGHT THERE, so this is pinned by assertion as well as by comment --
+        // test/unit/linkage-verdict-test.ts, `#234 + #241 -- recordId is null`.
+        //
+        // `AccessContext.recordId` (src/types/orm-types.ts, abofs/stonyx-orm#236 /
+        // #241) means "the record THIS ROUTE WAS ADDRESSED TO, as the store key of
+        // the model being authorised", and `null` means "addressed to no record".
+        // The id sitting on the request in hand names the PRIMARY record, which
+        // belongs to a DIFFERENT model -- `GET /owners/gina` carries
+        // `params.id === 'gina'`, and the ask being made HERE is about `animal` or
+        // `trait`. Filling this in from the request would hand the related model's
+        // predicate an id belonging to another model, which is byte-for-byte the
+        // cross-model confusion abofs/stonyx-orm#202 introduced this context to
+        // eliminate: the predicate would compare an owner's id against its own
+        // records and answer a question nobody asked. There is no record of THIS
+        // model addressed by this request, so `null` is the honest value -- the
+        // same spelling `auth()` uses for a collection route.
+        //
+        // NOR ANY RECORD'S OWN ID, WHICH IS THE SECOND-MOST TEMPTING ANSWER. This
+        // verdict is resolved ONCE PER TYPE and cached in `byType` below, before
+        // any record has been looked at; there is no per-record `AccessContext`
+        // built anywhere on this path. Seeding it from the first record of a type
+        // would let that record's identity answer for every later record of the
+        // same type -- the same "one record's verdict answers for another" defect
+        // the `decisions` raw-key argument below exists to prevent, just one level
+        // coarser. And it is unnecessary: `AccessContext` deliberately carries no
+        // `record` because auth-time and record-time are separate decision points,
+        // and the per-record point already receives the WHOLE record, id included,
+        // through `verdict.filter(record)`. A predicate that wants a record's id
+        // has the contract's own channel for it.
+        access = predicate(request, { model: type, operation: 'read', recordId: null });
     }
     catch (error) {
         log.error?.(`[@stonyx/orm] access() threw while resolving linkage for model "${type}" -- denying. ${error instanceof Error ? error.message : String(error)}`);

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
@@ -158,6 +167,11 @@
  * `/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
@@ -173,12 +187,26 @@
  *   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.
@@ -188,6 +216,20 @@
  * 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, and that
@@ -196,6 +238,12 @@
  * 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.
+ *
  * 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.