@stonyx/orm 0.3.2-alpha.61 → 0.3.2-alpha.62

package/README.md

@@ -315,15 +315,24 @@ 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 all five variants are **unconstructible** against it
+> rather than merely handled.
 >
 > 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.
+>
 > 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,27 +346,39 @@ 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();
+  access(request, { model, operation }) {
+    // `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 none of the five fail-open
+    // variants recorded in the header is constructible against this predicate
+    // any more; they are history, not rules to follow.
+    //
+    // `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
+    // per-verb, so it does not branch on it; the permission array at the bottom
+    // is where the verb is answered.
+
+    // FAIL CLOSED. `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. 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. false → 403 for the whole
+      // request.
+      //
+      // 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.
+      const path = String(request.path ?? '').toLowerCase();
 
-    if (collection.endsWith('/owners')) {
       if (path === '/archived' || path.startsWith('/archived/')) return false;
 
       // Returning a function plugs it in as a per-record filter, and it is
@@ -373,7 +394,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'];
@@ -523,9 +544,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 +555,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.
@@ -621,9 +651,17 @@ one both behave exactly as before.
 
 ### 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 |
 |---|---|---|
@@ -633,13 +671,19 @@ 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:
+**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.
 
-**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).
+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 all five variants are unconstructible against it rather than
+handled. 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` |
 |---|---|---|---|---|
@@ -650,21 +694,23 @@ 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.
+**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. Lower-case it before comparing: the router matched
+case-insensitively, so a case-sensitive sub-path rule is stricter than the router
+that dispatched the request and can be stepped around. Record ids are
+case-sensitive and must be compared at their real case.
+
+**Fail closed on anything you cannot identify.**
+`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 now applies to the context — the sample returns `false` for
+an absent `model` rather than falling through. An input you cannot identify must
+**deny**.
 
 ### Known limitations
 
@@ -687,11 +733,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

package/dist/manage-record.js

@@ -153,52 +153,17 @@ export function updateRecord(record, rawData, userOptions = {}) {
     }
 }
 /**
- * gets the next available id, based on the HIGHEST id present.
+ * gets the next available id based on last record entry.
  *
  * In MySQL mode with numeric IDs, assigns a temporary pending ID.
  * MySQL's AUTO_INCREMENT provides the real ID after INSERT.
- *
- * ---------------------------------------------------------------------------
- * WAS: `Array.from(storeMap.values()).at(-1).id + 1` — the LAST INSERTED id,
- * not the maximum (abofs/stonyx-orm#203). The store is a Map, so insertion
- * order stops being ascending the moment a record is deleted and recreated, a
- * db.json is written out of order, a directory-mode store is read back in file
- * order, or a caller POSTs a high id and then a low one. After that, every
- * server-assigned id is one that is ALREADY TAKEN — and `createRecord`'s
- * last-entry-wins branch then overwrites that record IN PLACE and answers 200.
- * No error, no 409, and the store's size does not change. That is the whole
- * defect, and it is reachable from a create with NO id at all, which is the
- * most ordinary write a consumer performs.
- *
- * Covered by test/unit/assign-record-id-test.ts. Note for anyone changing this
- * function: before that file existed, the whole suite scored 951/0 both on the
- * defect and on a naive `Math.max` fix that introduced a second one. A green
- * suite is not evidence here; those assertions are.
- * ---------------------------------------------------------------------------
  */
 function assignRecordId(modelName, rawData) {
-    // PRESENCE, not truthiness. `0` is a legal value for an `attr('number')` id,
-    // and `if (rawData.id) return` silently reassigned it, handing the caller back
-    // a different record than the one it named (#203).
-    //
-    // `''` is deliberately NOT honoured here and this is not an oversight: it is
-    // the one string that means "no id". `parseInt('')` is `NaN`, a record CAN be
-    // held under the key `NaN`, and orm-request.ts's body-id normalisation relies
-    // on `''` staying absent — otherwise `POST {"id":""}` answers 409 against a
-    // record it never named. Pinned by test/unit/assign-record-id-test.ts (AC6's
-    // BOUNDARY assertions) and by access-filter-enforcement-test.ts assertion 44.
-    // Widening this to `!== undefined` breaks both.
-    if (rawData.id || rawData.id === 0)
+    if (rawData.id)
         return;
     // In SQL mode with numeric IDs, defer to database auto-increment.
     // Use unique negative integers — they survive the number transform (parseInt preserves negatives)
     // and avoid NaN store-key collisions that string pending IDs caused.
-    //
-    // This early return is ABOVE the max computation on purpose: a pending
-    // negative must never be a candidate for, or be perturbed by, the max path.
-    // Pinned directly (AC5.3) rather than by asserting the max is unaffected —
-    // that assertion could not have failed, because nothing negative ever reaches
-    // the code below.
     if (Orm.instance?.sqlDb && !isStringIdModel(modelName)) {
         rawData.id = -(++pendingIdCounter);
         rawData.__pendingSqlId = true;
@@ -208,73 +173,13 @@ function assignRecordId(modelName, rawData) {
     if (!storeMap)
         throw new Error(`Cannot assign record ID: model "${modelName}" not found in store`);
     const modelStore = Array.from(storeMap.values()).filter(isOrmRecord);
-    // The shape of src/standalone-db.ts:134-137, and it is chosen over
-    // `Math.max(...ids)` for a reason that is measurable rather than stylistic:
-    // a store CAN hold a record under the key `NaN` (`{id: '   '}` is truthy, so
-    // it survives the guard above and NaNs in the number transform — that is the
-    // state access-filter-enforcement-test.ts assertion 44 constructs). `Math.max`
-    // returns `NaN` if any operand is `NaN`, so it would assign `NaN`, land on
-    // that slot and overwrite it — exactly the defect being fixed, in a new
-    // disguise. This reduce cannot: non-numbers are skipped, and `NaN > max` is
-    // `false`. Pinned by AC2.
-    const maxId = modelStore.reduce((max, record) => {
-        const recordId = record.id;
-        return typeof recordId === 'number' && recordId > max ? recordId : max;
-    }, 0);
-    // THE OCCUPANCY CHECK RUNS ON THE LANDING KEY, NOT ON THE RAW CANDIDATE, and
-    // the difference is a silent data loss rather than a nicety.
-    //
-    // `createRecord` looks the record up under `rawData.id` (:50) but WRITES it
-    // under `record.id` (:69) — the value after the model's declared id transform
-    // has run inside `serialize`. On a string-id model those two differ: the
-    // number `1` is looked up, the record lands under the string `'1'`. A guard
-    // written as `storeMap.has(rawData.id)` therefore checks a key the record will
-    // never occupy, misses an occupied slot and overwrites it — measured: owner
-    // '1' age 55 -> 9, store size unchanged, no error. That is abofs/stonyx-orm
-    // #205's lookup-key/landing-key divergence reappearing inside #203's own fix,
-    // which is why AC4 exists and why `rawData.id` is set to the LANDING key
-    // below: it makes :50 and :69 agree by construction.
-    //
-    // Termination: with an injective id transform at most `storeMap.size`
-    // candidates can be occupied. A NON-injective id type would otherwise spin
-    // forever, so the loop is bounded and exits with a defined error the route can
-    // report instead of hanging the request.
-    //
-    // Resolved ONCE, outside the loop: `getIdType` instantiates the model class,
-    // so resolving it per candidate would put a model construction on every
-    // iteration of a loop that exists to walk past occupied slots.
-    const toStoreKey = storeKeyDeriver(modelName);
-    let candidate = maxId + 1;
-    let landingKey = toStoreKey(candidate);
-    let attempts = 0;
-    while (storeMap.has(landingKey)) {
-        if (++attempts > storeMap.size) {
-            throw new Error(`Cannot assign record ID: no free id available for model "${modelName}"`);
-        }
-        candidate += 1;
-        landingKey = toStoreKey(candidate);
-    }
-    rawData.id = landingKey;
-}
-/**
- * Returns the derivation that maps an id VALUE to the store KEY a record
- * carrying it will actually be filed under — the model's declared id transform,
- * the same one `serialize` runs at createRecord:68 before the `.set` at :69.
- */
-function storeKeyDeriver(modelName) {
-    const idType = getIdType(modelName);
-    const transform = idType ? Orm.instance?.transforms?.[idType] : undefined;
-    if (typeof transform !== 'function')
-        return value => value;
-    return value => transform(value);
+    const lastRecord = modelStore.at(-1);
+    rawData.id = lastRecord ? lastRecord.id + 1 : 1;
 }
-function getIdType(modelName) {
-    const modelClass = Orm.instance?.getRecordClasses(modelName).modelClass;
+function isStringIdModel(modelName) {
+    const modelClass = Orm.instance.getRecordClasses(modelName).modelClass;
     if (!modelClass)
-        return undefined;
+        return false;
     const model = new modelClass(modelName);
-    return model.id?.type;
-}
-function isStringIdModel(modelName) {
-    return getIdType(modelName) === 'string';
+    return model.id?.type === 'string';
 }

package/dist/orm-request.d.ts

@@ -98,8 +98,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 +110,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.)
- *
- * 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.
+ * its collection from the request. (Asserted on a live dispatch by AC9 in
+ * test/integration/orm-test.ts, against a deliberately arity-1 predicate.)
+ *
+ * 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 +152,31 @@
  *      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:
- *
- *   `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.
+ * 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`.
+ *
+ *   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 all five variants are
+ *   unconstructible against a migrated predicate rather than handled.
+ *
+ * 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.
+ * Lower-case it before comparing -- the router matched case-insensitively -- and
+ * compare record ids at their real case.
  *
  * `?? ''` 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 the context too: the sample returns `false` for an absent `model`
+ * rather than falling through.
  *
- * 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.

package/dist/orm-request.js

@@ -98,8 +98,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 +110,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 +152,31 @@
  *      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`.
  *
- *   `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.
+ *   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 all five variants are
+ *   unconstructible against a migrated predicate rather than handled.
+ *
+ * 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.
+ * Lower-case it before comparing -- the router matched case-insensitively -- and
+ * compare record ids at their real case.
  *
  * `?? ''` 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 the context too: the sample returns `false` for an absent `model`
+ * rather than falling through.
  *
- * 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.

package/package.json

@@ -4,7 +4,7 @@
     "stonyx-async",
     "stonyx-module"
   ],
-  "version": "0.3.2-alpha.61",
+  "version": "0.3.2-alpha.62",
   "description": "",
   "main": "dist/index.js",
   "type": "module",

package/src/manage-record.ts

@@ -195,52 +195,17 @@ export function updateRecord(record: OrmRecord, rawData: unknown, userOptions: C
 }
 
 /**
- * gets the next available id, based on the HIGHEST id present.
+ * gets the next available id based on last record entry.
  *
  * In MySQL mode with numeric IDs, assigns a temporary pending ID.
  * MySQL's AUTO_INCREMENT provides the real ID after INSERT.
- *
- * ---------------------------------------------------------------------------
- * WAS: `Array.from(storeMap.values()).at(-1).id + 1` — the LAST INSERTED id,
- * not the maximum (abofs/stonyx-orm#203). The store is a Map, so insertion
- * order stops being ascending the moment a record is deleted and recreated, a
- * db.json is written out of order, a directory-mode store is read back in file
- * order, or a caller POSTs a high id and then a low one. After that, every
- * server-assigned id is one that is ALREADY TAKEN — and `createRecord`'s
- * last-entry-wins branch then overwrites that record IN PLACE and answers 200.
- * No error, no 409, and the store's size does not change. That is the whole
- * defect, and it is reachable from a create with NO id at all, which is the
- * most ordinary write a consumer performs.
- *
- * Covered by test/unit/assign-record-id-test.ts. Note for anyone changing this
- * function: before that file existed, the whole suite scored 951/0 both on the
- * defect and on a naive `Math.max` fix that introduced a second one. A green
- * suite is not evidence here; those assertions are.
- * ---------------------------------------------------------------------------
  */
 function assignRecordId(modelName: string, rawData: { [key: string]: unknown }): void {
-  // PRESENCE, not truthiness. `0` is a legal value for an `attr('number')` id,
-  // and `if (rawData.id) return` silently reassigned it, handing the caller back
-  // a different record than the one it named (#203).
-  //
-  // `''` is deliberately NOT honoured here and this is not an oversight: it is
-  // the one string that means "no id". `parseInt('')` is `NaN`, a record CAN be
-  // held under the key `NaN`, and orm-request.ts's body-id normalisation relies
-  // on `''` staying absent — otherwise `POST {"id":""}` answers 409 against a
-  // record it never named. Pinned by test/unit/assign-record-id-test.ts (AC6's
-  // BOUNDARY assertions) and by access-filter-enforcement-test.ts assertion 44.
-  // Widening this to `!== undefined` breaks both.
-  if (rawData.id || rawData.id === 0) return;
+  if (rawData.id) return;
 
   // In SQL mode with numeric IDs, defer to database auto-increment.
   // Use unique negative integers — they survive the number transform (parseInt preserves negatives)
   // and avoid NaN store-key collisions that string pending IDs caused.
-  //
-  // This early return is ABOVE the max computation on purpose: a pending
-  // negative must never be a candidate for, or be perturbed by, the max path.
-  // Pinned directly (AC5.3) rather than by asserting the max is unaffected —
-  // that assertion could not have failed, because nothing negative ever reaches
-  // the code below.
   if (Orm.instance?.sqlDb && !isStringIdModel(modelName)) {
     rawData.id = -(++pendingIdCounter);
     rawData.__pendingSqlId = true;
@@ -250,85 +215,15 @@ function assignRecordId(modelName: string, rawData: { [key: string]: unknown }):
   const storeMap = store.get(modelName);
   if (!storeMap) throw new Error(`Cannot assign record ID: model "${modelName}" not found in store`);
   const modelStore = Array.from(storeMap.values()).filter(isOrmRecord);
-
-  // The shape of src/standalone-db.ts:134-137, and it is chosen over
-  // `Math.max(...ids)` for a reason that is measurable rather than stylistic:
-  // a store CAN hold a record under the key `NaN` (`{id: '   '}` is truthy, so
-  // it survives the guard above and NaNs in the number transform — that is the
-  // state access-filter-enforcement-test.ts assertion 44 constructs). `Math.max`
-  // returns `NaN` if any operand is `NaN`, so it would assign `NaN`, land on
-  // that slot and overwrite it — exactly the defect being fixed, in a new
-  // disguise. This reduce cannot: non-numbers are skipped, and `NaN > max` is
-  // `false`. Pinned by AC2.
-  const maxId = modelStore.reduce((max: number, record) => {
-    const recordId = record.id as unknown;
-
-    return typeof recordId === 'number' && recordId > max ? recordId : max;
-  }, 0);
-
-  // THE OCCUPANCY CHECK RUNS ON THE LANDING KEY, NOT ON THE RAW CANDIDATE, and
-  // the difference is a silent data loss rather than a nicety.
-  //
-  // `createRecord` looks the record up under `rawData.id` (:50) but WRITES it
-  // under `record.id` (:69) — the value after the model's declared id transform
-  // has run inside `serialize`. On a string-id model those two differ: the
-  // number `1` is looked up, the record lands under the string `'1'`. A guard
-  // written as `storeMap.has(rawData.id)` therefore checks a key the record will
-  // never occupy, misses an occupied slot and overwrites it — measured: owner
-  // '1' age 55 -> 9, store size unchanged, no error. That is abofs/stonyx-orm
-  // #205's lookup-key/landing-key divergence reappearing inside #203's own fix,
-  // which is why AC4 exists and why `rawData.id` is set to the LANDING key
-  // below: it makes :50 and :69 agree by construction.
-  //
-  // Termination: with an injective id transform at most `storeMap.size`
-  // candidates can be occupied. A NON-injective id type would otherwise spin
-  // forever, so the loop is bounded and exits with a defined error the route can
-  // report instead of hanging the request.
-  //
-  // Resolved ONCE, outside the loop: `getIdType` instantiates the model class,
-  // so resolving it per candidate would put a model construction on every
-  // iteration of a loop that exists to walk past occupied slots.
-  const toStoreKey = storeKeyDeriver(modelName);
-
-  let candidate = maxId + 1;
-  let landingKey = toStoreKey(candidate);
-  let attempts = 0;
-
-  while (storeMap.has(landingKey)) {
-    if (++attempts > storeMap.size) {
-      throw new Error(`Cannot assign record ID: no free id available for model "${modelName}"`);
-    }
-
-    candidate += 1;
-    landingKey = toStoreKey(candidate);
-  }
-
-  rawData.id = landingKey;
+  const lastRecord = modelStore.at(-1);
+  rawData.id = lastRecord ? (lastRecord.id as number) + 1 : 1;
 }
 
-/**
- * Returns the derivation that maps an id VALUE to the store KEY a record
- * carrying it will actually be filed under — the model's declared id transform,
- * the same one `serialize` runs at createRecord:68 before the `.set` at :69.
- */
-function storeKeyDeriver(modelName: string): (value: number) => number | string {
-  const idType = getIdType(modelName);
-  const transform = idType ? Orm.instance?.transforms?.[idType] : undefined;
-
-  if (typeof transform !== 'function') return value => value;
-
-  return value => transform(value) as number | string;
-}
-
-function getIdType(modelName: string): string | undefined {
-  const modelClass = Orm.instance?.getRecordClasses(modelName).modelClass as (new (name: string) => { [key: string]: unknown }) | undefined;
-  if (!modelClass) return undefined;
+function isStringIdModel(modelName: string): boolean {
+  const modelClass = Orm.instance.getRecordClasses(modelName).modelClass as (new (name: string) => { [key: string]: unknown }) | undefined;
+  if (!modelClass) return false;
 
   const model = new modelClass(modelName);
 
-  return (model.id as { type?: string } | undefined)?.type;
-}
-
-function isStringIdModel(modelName: string): boolean {
-  return getIdType(modelName) === 'string';
+  return (model.id as { type?: string } | undefined)?.type === 'string';
 }

package/src/orm-request.ts

@@ -98,8 +98,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 +110,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 +152,31 @@
  *      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`.
  *
- *   `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.
+ *   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 all five variants are
+ *   unconstructible against a migrated predicate rather than handled.
+ *
+ * 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.
+ * Lower-case it before comparing -- the router matched case-insensitively -- and
+ * compare record ids at their real case.
  *
  * `?? ''` 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 the context too: the sample returns `false` for an absent `model`
+ * rather than falling through.
  *
- * 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.