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

package/README.md

@@ -581,7 +581,7 @@ a write to a *different* collection can still re-parent one. See
 | `GET /:models/:id/relationships/{relationship}` | `404` — same |
 | `PATCH /:models/:id` | `404`, no attribute is applied |
 | `DELETE /:models/:id` | `404`, the record is not removed and no SQL `DELETE` is issued |
-| `POST /:models` | `403`, and a record **this request inserted** is rolled back — see [Known limitations](#known-limitations) for the case where it did not insert one |
+| `POST /:models` | `403`, and a record **this request inserted** is rolled back — see [Known limitations](#known-limitations) for why the rollback is conditional |
 
 **Denied record-level requests return 404, not 403.** This is deliberate and it
 is the property most easily "improved" away. 403 would confirm that the record
@@ -615,9 +615,29 @@ chooses the id and learns whether the create succeeded — so under a filter the
 caller does not choose the id. The refusal happens before any store lookup, so
 neither the status nor the response time depends on whether the id exists.
 
-Let the server assign the id and read it back from the response. Callers with no
-function-style filter are unaffected: `409` on a duplicate id and `200` on a free
-one both behave exactly as before.
+Let the server assign the id and read it back from the response — and read it
+back rather than predicting it, because the value it returns is documented but
+not stable across model kinds: a numeric-id model gets `max + 1` (or, at the
+numeric ceiling, the lowest free integer), and a string-id model gets
+`<model>-<n>`. See breaking change 8.
+
+**What a server-assigned id is not.** It is not a secret. On a string-id
+collection it is dense and enumerable from `1`, where previously it inherited
+whatever entropy the last-inserted id happened to carry — a UUID-seeded store
+answered a UUID-derived key. If a collection has **no** `access` config its
+record-level routes are ungated, so the id was the only thing standing between
+an unauthenticated caller and `GET`/`PATCH`/`DELETE` on a record. That was never
+a control and must not become one; configure `access`.
+
+**And the id itself is an occupancy signal.** `assignRecordId` reads the whole
+store, not the caller's filtered view — it never sees `state.filter` — so the id
+it returns is a function of records the caller may not be permitted to read. On
+a string-id collection the assigned `n` is the smallest positive integer whose
+key is free, which tells the caller that every key below it is taken, hidden or
+not. Closing that requires the assignment to be filter-aware, which is a change
+to the `access` contract rather than a fix; it is stated here rather than left
+to be discovered. Callers with no function-style filter are unaffected — there
+are no hidden records to disclose.
 
 ### Identifying the collection
 
@@ -743,9 +763,10 @@ sub-paths beneath the mount, as the `/archived` deny above does.
   transform output differs from its lookup key is the same defect. Filtered
   collections are unaffected — breaking change 3 refuses any client-supplied id
   — so this reaches consumers with **no** function-style filter. Tracked as
-  [#205](https://github.com/abofs/stonyx-orm/issues/205), alongside
-  [#203](https://github.com/abofs/stonyx-orm/issues/203), which is the other way
-  a create can land on an id nobody named.
+  [#205](https://github.com/abofs/stonyx-orm/issues/205). Its sibling
+  [#203](https://github.com/abofs/stonyx-orm/issues/203) — a **server-assigned**
+  id landing on an occupied slot — is **fixed**; see breaking change 8. #205 is
+  the client-supplied half and is still open.
 - **`context.record` is `undefined` for an after-`create` hook when a string-id
   model is given a numeric-looking id.** The post-create lookup uses the same id
   coercion as every other surface, which resolves `'9107'` to the number `9107`,
@@ -755,15 +776,18 @@ sub-paths beneath the mount, as the `/archived` deny above does.
   [#209](https://github.com/abofs/stonyx-orm/issues/209).
 - **A denied `POST` rolls back only a record it *inserted*.** The rollback
   requires the store to have grown, because removing by id alone is a write
-  primitive keyed by a caller-supplied value. When `assignRecordId` lands a
-  **server-assigned** id on an occupied slot
-  ([#203](https://github.com/abofs/stonyx-orm/issues/203) — it returns
-  last-*inserted* + 1, not max + 1, so a store whose insertion order is not
-  ascending collides), `createRecord` updates that record **in place**: the map
-  does not grow, the rollback correctly declines to remove a record this request
-  did not create, and the `403` leaves the caller's attributes on someone else's
-  record. Narrow — it needs a non-ascending insertion order — but it is the
-  reachability condition, so it is stated rather than implied.
+  primitive keyed by a caller-supplied value. **The reachability condition this
+  bullet used to state is gone**: it was
+  [#203](https://github.com/abofs/stonyx-orm/issues/203) — `assignRecordId`
+  returned last-*inserted* + 1, so a server-assigned id could land on an
+  occupied slot and `createRecord` would update it in place — and #203 is fixed
+  (breaking change 8). A server-assigned create can no longer overwrite, so on a
+  collection whose only id channel is `createHandler` this guard has no
+  observable effect today. It is kept because a caller-supplied id reaching
+  `createRecord` from another route — a relationship write,
+  [#207](https://github.com/abofs/stonyx-orm/issues/207) — puts the condition
+  back, and without the guard a denied `403` would delete a record the request
+  did not create.
 
 ### Breaking changes
 
@@ -824,6 +848,39 @@ they are recorded here.
    population breaking changes 3 and 4 explicitly exempt. If you were relying on
    a hex-shaped or whitespace-padded id creating a second record, it never did.
 
+8. **Server-assigned ids change value on string-id models, and the create route
+   gains a `409`.** Two consumer-visible changes from
+   [#203](https://github.com/abofs/stonyx-orm/issues/203).
+
+   **The value.** A `POST` with no `id` against a model declaring
+   `id = attr('string')` previously produced the *last-inserted* id with `1`
+   concatenated onto it — an owner store holding `['gina', 'bob']` answered
+   `'bob1'`. It now answers `'owner-1'`: the model name, a hyphen, and the
+   lowest positive integer whose landing key is free. **No test in this repo
+   pinned the old value**, so a consumer relying on it gets no failing test, no
+   deprecation and no other signal — which is why it is recorded here. Numeric
+   id models (`id = attr('number')`, the default) are unaffected in shape: they
+   still get an integer, but it is now the **maximum** existing id plus one
+   rather than the last-inserted id plus one, which is the defect #203 is about.
+
+   The value is deliberately **not** numeric-looking, and that is not cosmetic.
+   Every id-bearing surface resolves a numeric-looking string id to a **number**
+   (`GET /owners/1` looks up `1`), while a string-id model files its records
+   under the **string** key `'1'`. A server-assigned `'1'` would therefore be a
+   record that was created successfully and could not be fetched, updated or
+   deleted by id, and whose after-`create` hook received
+   `context.record === undefined`
+   ([#209](https://github.com/abofs/stonyx-orm/issues/209)).
+
+   **The status.** `POST /{collection}` can now answer `409` for a reason other
+   than a duplicate id: the server could not derive a free id. That requires a
+   **non-injective** id transform — one that maps distinct candidates onto the
+   same store key, such as `boolean`, or anything you registered on
+   `Orm.instance.transforms` and named as an id type. It is a configuration
+   fault rather than a request fault; the message is logged through
+   `stonyx/log`. Previously this case threw out of the handler and express
+   answered `500` with a stack trace.
+
 ### Include Parameter (Sideloading Relationships)
 
 The ORM supports JSON API-compliant relationship sideloading via the `include` query parameter. This reduces the need for multiple API requests by embedding related records in a single response.

package/dist/manage-record.js

@@ -1,7 +1,7 @@
 import Orm, { store } from '@stonyx/orm';
 import OrmRecord from './record.js';
 import { getGlobalRegistry, getPendingRegistry, getPendingBelongsToRegistry, getBelongsToRegistry, getHasManyRegistry } from './relationships.js';
-import { isOrmRecord } from './utils.js';
+import { isOrmRecord, maxNumericId, NO_FREE_ID_ERROR } from './utils.js';
 const defaultOptions = {
     isDbRecord: false,
     serialize: true,
@@ -185,9 +185,15 @@ function assignRecordId(modelName, rawData) {
     // 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.
+    // record it never named.
+    //
+    // WHAT WIDENING THIS TO `!== undefined` ACTUALLY DOES, measured rather than
+    // asserted: `{id: ''}` early-returns, `parseInt('')` NaNs it, and the record
+    // lands on the store's `NaN` slot and OVERWRITES whatever is there — #203's
+    // own defect class. It does NOT turn access-filter-enforcement-test.ts
+    // assertion 44 red; an earlier revision of this comment claimed it did, which
+    // converted an unknown into a false assurance. AC6's BOUNDARY assertions are
+    // what catch it, and they only do so because they seed the `NaN` slot first.
     if (rawData.id || rawData.id === 0)
         return;
     // In SQL mode with numeric IDs, defer to database auto-increment.
@@ -208,53 +214,142 @@ 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);
+    // ONE COPY of the max-numeric-id reduce, in src/utils.ts. There were three
+    // (here, StandaloneDB.create, and the #203 test helper) and `docs/
+    // improvements.md`'s WET Code category prescribes the extraction. What that
+    // helper must NOT be is `Math.max(...ids)`; the reason is measured and it is
+    // documented at the helper rather than duplicated here. Pinned by AC2.
+    const maxId = maxNumericId(modelStore);
     // 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.
+    // has run inside `serialize`. When the transform is not the identity those two
+    // differ, so a guard written as `storeMap.has(rawData.id)` checks a key the
+    // record will never occupy, misses an occupied slot and overwrites it —
+    // measured on an `uppercase`-id model: the guard checks `owner-1`, the record
+    // lands under `OWNER-1`, 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.
     //
-    // 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.
+    // THE SCOPE OF THAT CLAIM, stated rather than implied. Setting `rawData.id` to
+    // the landing key makes :50 and :69 agree for every IDEMPOTENT id transform —
+    // `number`, `float`, `string`, `passthrough`, `uppercase`, `trim`. It does NOT
+    // make them agree for `date` or `timestamp`: `transforms.date` returns a NEW
+    // object every call and a `Map` keys by identity, so `storeMap.has(landingKey)`
+    // is always `false` there and the occupancy check is vacuous. `dev` is broken
+    // for those types too — this is not a regression — but no comment here may
+    // claim a property it was not measured to have (#212 § AC5).
     //
-    // Resolved ONCE, outside the loop: `getIdType` instantiates the model class,
+    // Resolved ONCE, outside the walk: `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);
+    // DOES THIS MODEL FILE ITS RECORDS UNDER STRING KEYS? Decided by RUNNING the
+    // model's own id transform once, not by matching a type NAME against a list:
+    // `Orm.instance.transforms` (main.ts:70) is a public, MUTABLE instance
+    // property, so any enumeration of "the string-ish types" written here would be
+    // wrong the moment a consumer registers one.
+    const stringKeyed = typeof toStoreKey(maxId + 1) === 'string';
+    // THE CANDIDATE FOR A STRING-KEYED MODEL IS NOT A BARE NUMBER, and this is
+    // abofs/stonyx-orm#209 — which is REOPENED — not aesthetics.
+    //
+    // `orm-request.ts`'s `coerceId` (:322) resolves a NUMERIC-LOOKING string to a
+    // NUMBER on every id-bearing surface, while a model declaring
+    // `id = attr('string')` files under the STRING key. So a server-assigned `'1'`
+    // produces a record that is created and then NOT ADDRESSABLE. Measured over
+    // the route, owner store `{'1': ...}`:
+    //
+    //   GET    /owners/1       -> 404      (the record exists)
+    //   DELETE /owners/1       -> 404
+    //   GET    /owners/owner-1 -> 200
+    //
+    // and `_withHooks` (:1185) hands an after-`create` hook
+    // `context.record === undefined` for the same reason. `dev` assigned `'bob1'`,
+    // which is not numeric-looking, so `dev` has neither problem: a bare-number
+    // candidate would move #209 from "a caller supplied a numeric-looking id" onto
+    // the DEFAULT path for every server-assigned create on every string-id model.
+    // Prefixing with the model name keeps #209's population exactly as narrow as
+    // it already was, without touching the one shared coercion or the assertion
+    // that pins #209 open. Pinned by AC3.
+    const toCandidate = stringKeyed
+        ? (value) => `${modelName}-${value}`
+        : (value) => value;
+    // `maxId + 1` is the id AC1 pins: strictly greater than every numeric key
+    // present. IT IS NOT ALWAYS AVAILABLE, and that gap was a live denial of
+    // service. Float64 has no integer successor at or above 2^53, so
+    // `maxId + 1 === maxId` for every `maxId >= 9007199254740992` and `+ 1` inside
+    // the walk is a NO-OP there. One record filed under that key — which an
+    // unauthenticated `POST {"id":9007199254740992}` puts there, and which reaches
+    // even a filter-protected collection through has-many.ts:65 (#207), a channel
+    // GATE 0 does not cover — made the walk unable to advance, so it exhausted its
+    // budget and threw on EVERY subsequent server-assigned create, permanently,
+    // until that record was deleted. Measured over the route: 200, then 500 for
+    // every no-id create. `dev` answers 200.
+    //
+    // So a store holding one adversarial record must not disable its collection.
+    // When "above the max" is not a usable strategy the walk RESTARTS FROM 1: the
+    // store holds at most `size` keys, so one of `1 .. size + 1` is always free
+    // under an injective id transform. Pinned by AC7.
+    const start = maxId + 1;
+    let landingKey = firstFreeKey(storeMap, toStoreKey, toCandidate, start);
+    // THE RESTART, and it is the whole of the ceiling fix. Killing mutation:
+    // delete this block -> AC7 goes red (the route answers 409 instead of the
+    // created resource).
+    if (landingKey === NO_FREE_KEY && start !== 1) {
+        landingKey = firstFreeKey(storeMap, toStoreKey, toCandidate, 1);
+    }
+    if (landingKey === NO_FREE_KEY) {
+        // Reachable only with a NON-INJECTIVE id transform — see `firstFreeKey`.
+        // `createHandler` matches this message and answers 409 rather than letting it
+        // reach express's default handler, which serialises a stack trace with
+        // absolute install paths outside NODE_ENV=production (the hazard
+        // orm-request.ts:553-558 exists to name). Pinned by AC8.
+        throw new Error(`${NO_FREE_ID_ERROR} for model "${modelName}"`);
+    }
+    rawData.id = landingKey;
+}
+// Returned instead of a key so that "no key" cannot be confused with a transform
+// that legitimately produced `undefined` or `null`.
+const NO_FREE_KEY = Symbol('no free store key');
+/**
+ * The first store key at or above `start` that no record occupies, walking
+ * candidate ids upward, or `NO_FREE_KEY` if the walk cannot reach one.
+ */
+function firstFreeKey(storeMap, toStoreKey, toCandidate, start) {
+    let candidate = start;
+    let landingKey = toStoreKey(toCandidate(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}"`);
-        }
+        // THE BOUND IS EXACTLY TIGHT, not conservative: this walk tries
+        // `storeMap.size + 1` DISTINCT candidates against at most `storeMap.size`
+        // occupied keys, so under an injective `toStoreKey` it provably cannot fire.
+        // Under a non-injective one it provably terminates — and that is a reachable
+        // consumer state rather than a hypothesis: `transforms.boolean`
+        // (transforms.ts:4) collapses every candidate onto `true`/`false`, and
+        // `Orm.instance.transforms` (main.ts:70) is public and MUTABLE, so a consumer
+        // can register an arbitrary non-injective transform and name it as an id
+        // type. Without this, a no-id create spins forever inside a synchronous store
+        // walk and pins a worker, which is worse than either collision policy. Its
+        // EXISTENCE and its THRESHOLD are both pinned by AC8: deleting it makes AC8
+        // HANG rather than fail, and weakening it to fire on the first collision
+        // makes AC8.1 red.
+        if (++attempts > storeMap.size)
+            return NO_FREE_KEY;
+        // NOTE FOR ANYONE ADDING A SECOND EXIT HERE. A `candidate + 1 === candidate`
+        // float-saturation check was written, measured, and REMOVED: with the
+        // restart-from-1 above in place, deleting the saturation check leaves the
+        // whole suite green, because the budget reaches the same `NO_FREE_KEY` one
+        // pass later and the restart still answers. An unkillable guard in a change
+        // whose deliverable is falsifiable coverage is exactly what this story exists
+        // to stop shipping. `+ 1` being a no-op at 2^53 costs `size` extra `Map.has`
+        // calls on that one path and changes no outcome.
         candidate += 1;
-        landingKey = toStoreKey(candidate);
+        landingKey = toStoreKey(toCandidate(candidate));
     }
-    rawData.id = landingKey;
+    return landingKey;
 }
 /**
  * Returns the derivation that maps an id VALUE to the store KEY a record
@@ -264,9 +359,44 @@ function assignRecordId(modelName, rawData) {
 function storeKeyDeriver(modelName) {
     const idType = getIdType(modelName);
     const transform = idType ? Orm.instance?.transforms?.[idType] : undefined;
+    // SURVIVOR, RETAINED, with its reachability condition stated rather than left
+    // silent — `docs/project-structure.md` § "unkillable code reads as coverage and
+    // is not" is the standing rule and it applies outside orm-request.ts too.
+    //
+    // No mutation in this repo can kill this branch, and that is STRUCTURAL rather
+    // than an untested gap: `Model` declares `id = attr('number')` (model.ts:15) so
+    // every registered model has an id type; `ModelProperty` refuses a type with no
+    // registered transform (model-property.ts:4) so a declared type always
+    // resolves; and `getIdType` can therefore only return `undefined` when
+    // `getRecordClasses` yields no `modelClass` — in which case `createRecord`
+    // throws at :62 a few lines later regardless, so no record is ever filed
+    // through this branch.
+    //
+    // BECOMES REACHABLE if a model can be declared without an `id` property, if a
+    // store map can exist for a model with no registered class, or if
+    // `createRecord` stops constructing the model class. Kept rather than deleted
+    // because the alternative on that path is a `transform is not a function`
+    // TypeError, and because identity is exactly what `createRecord` would file
+    // under when no transform exists — the two agree, which is the property AC4 is
+    // about.
     if (typeof transform !== 'function')
         return value => value;
-    return value => transform(value);
+    return value => {
+        try {
+            return transform(value);
+        }
+        catch {
+            // `uppercase` and `trim` (transforms.ts:11-12) call a string method on the
+            // value directly, so a NUMERIC candidate throws `value?.toUpperCase is not
+            // a function`. On `dev` they never saw one — `lastRecord.id + 1` on a
+            // string id is a string — so feeding them a number here would regress a
+            // legal, registered id type into an uncaught 500. The retry feeds the
+            // string form, which is the shape an id actually arrives in off a JSON body
+            // or a URL param. A transform that throws on BOTH shapes still propagates.
+            // Pinned by AC9.
+            return transform(String(value));
+        }
+    };
 }
 function getIdType(modelName) {
     const modelClass = Orm.instance?.getRecordClasses(modelName).modelClass;

package/dist/orm-request.js

@@ -183,7 +183,7 @@ import { getPluralName } from './plural-registry.js';
 import { getBeforeHooks, getAfterHooks } from './hooks.js';
 import config from 'stonyx/config';
 import log from 'stonyx/log';
-import { isOrmRecord } from './utils.js';
+import { isOrmRecord, NO_FREE_ID_ERROR } from './utils.js';
 const methodAccessMap = {
     GET: 'read',
     POST: 'create',
@@ -676,7 +676,39 @@ export default class OrmRequest extends Request {
             // is true for a record the request did not create. The map's size is the
             // only O(1) signal that distinguishes an insert from an overwrite.
             const slotsBefore = store.get(model)?.size ?? 0;
-            const created = createRecord(model, recordAttributes, { serialize: false, _skipAutoPersist: true });
+            // THE ONE `createRecord` FAILURE THIS ROUTE ANSWERS RATHER THAN
+            // PROPAGATES, and it is narrow on purpose.
+            //
+            // `assignRecordId` throws when it cannot derive a free store key for a
+            // server-assigned id. Unguarded that rejection is auto-forwarded -- there
+            // is no catch here, none in @stonyx/rest-server's dispatcher
+            // (dist/request.js:41-70), and express 5 hands it to its default error
+            // handler, which serialises the STACK, with absolute install paths and the
+            // internal module graph, to an unauthenticated caller outside
+            // NODE_ENV=production. That is the hazard :553-558 already names in this
+            // file, and every sibling refusal in this handler returns an integer
+            // status instead. So this one returns 409, matching the client-duplicate
+            // refusal at :713: the caller asked for a record and the collection has no
+            // id to give it.
+            //
+            // MATCHED ON THE SHARED PREFIX, not on a literal, and NOT by catching
+            // everything: `createRecord` also throws for "ORM is not ready", a
+            // read-only view and an unregistered model store, and turning any of those
+            // into a 409 would report a configuration fault as a conflict. Anything
+            // else is re-thrown unchanged.
+            let created;
+            try {
+                created = createRecord(model, recordAttributes, { serialize: false, _skipAutoPersist: true });
+            }
+            catch (error) {
+                if (!(error instanceof Error) || !error.message.startsWith(NO_FREE_ID_ERROR))
+                    throw error;
+                // Not silently. A collection that can no longer assign an id is a
+                // configuration fault (a non-injective id transform), and a bare 409
+                // with no diagnostic is indistinguishable from an ordinary duplicate.
+                log.error?.(`[@stonyx/orm] ${error.message}`);
+                return 409; // Conflict
+            }
             const record = isOrmRecord(created) ? created : null;
             if (!record)
                 return 500;
@@ -700,11 +732,32 @@ export default class OrmRequest extends Request {
                 //
                 // Both conditions are required and neither implies the other:
                 //   createdNewSlot -- the store grew, so this request inserted rather
-                //                     than overwrote. Guards `assignRecordId` picking an
-                //                     id that is already taken (it returns
-                //                     last-INSERTED + 1, not max + 1, so a store whose
-                //                     insertion order is not ascending collides) -- see
-                //                     abofs/stonyx-orm#203.
+                //                     than overwrote. SURVIVOR AS OF #203, AND THAT IS
+                //                     WHAT THIS NOTE IS FOR. It used to be killable:
+                //                     `assignRecordId` returned last-INSERTED + 1, so a
+                //                     server-assigned id could land on an occupied slot,
+                //                     `createRecord` updated in place, and removing this
+                //                     half turned access-filter-enforcement-test.ts
+                //                     assertion 31 red. #203 closed that: the
+                //                     server-assigned path now walks past occupied keys,
+                //                     so no create reaching here can overwrite. Measured
+                //                     -- delete `createdNewSlot &&` below: `dev` gives
+                //                     55 pass / 1 fail with assertion 31 RED, this tree
+                //                     gives 56 pass / 0 fail, GREEN.
+                //                     KEPT ANYWAY, AND NOT FOR THE OLD REASON. Without
+                //                     it a denied create becomes `store.remove` on a key
+                //                     the caller may have influenced, which :815-820
+                //                     records as having been an unauthenticated deletion
+                //                     primitive across the whole id space. BECOMES
+                //                     KILLABLE AGAIN the moment any caller-supplied id
+                //                     can reach `createRecord` from this handler --
+                //                     which is exactly what has-many.ts:65 and
+                //                     belongs-to.ts:45 already do for ANOTHER model's
+                //                     store (abofs/stonyx-orm#207), and what a third
+                //                     un-stripped id channel would do for this one
+                //                     (#204). Do not delete it on the strength of #203
+                //                     being closed; that is the reasoning :862-867 warns
+                //                     about, one level up.
                 //   identity       -- the slot still holds the object we just created,
                 //                     so nothing between createRecord and here replaced
                 //                     it. Deleting this half SURVIVES the suite, and it

package/dist/standalone-db.js

@@ -7,6 +7,10 @@
  */
 import fs from 'fs/promises';
 import path from 'path';
+// `./utils.js` pulls in `@stonyx/utils/string` and nothing else -- no ORM
+// bootstrap, no `@stonyx/orm` index, no side effects -- so the "no framework
+// dependencies" property above still holds.
+import { maxNumericId } from './utils.js';
 export default class StandaloneDB {
     mode;
     dbPath;
@@ -102,11 +106,19 @@ export default class StandaloneDB {
     async create(collection, data) {
         const records = await this.readCollection(collection);
         if (!data.id) {
-            const maxId = records.reduce((max, r) => {
-                const rid = typeof r.id === 'number' ? r.id : 0;
-                return rid > max ? rid : max;
-            }, 0);
-            data.id = maxId + 1;
+            // SHARED WITH `assignRecordId` (src/manage-record.ts), which is the other
+            // place this repo picks a server-assigned id. It was a second copy of the
+            // reduce, and nothing here pointed at it — a maintainer editing this
+            // method could not discover the other existed. See `maxNumericId` for why
+            // it is not `Math.max` (abofs/stonyx-orm#203).
+            //
+            // THE TWO ARE NOT THE SAME FUNCTION beyond this line, deliberately.
+            // `StandaloneDB` has no model, id-type or transform concept, so `maxId + 1`
+            // IS its store key; `assignRecordId` has to map the candidate through the
+            // model's declared id transform first, and then walk past occupied keys.
+            // Transplanting this method's remaining logic into the ORM reproduces
+            // #203's landing-key defect exactly — which is what AC4 pins.
+            data.id = maxNumericId(records) + 1;
         }
         // Check for duplicate id
         const existing = records.find(r => r.id === data.id);

package/dist/utils.d.ts

@@ -5,3 +5,47 @@ export declare function isDbError(error: unknown): error is {
 };
 export declare function isOrmRecord(value: unknown): value is OrmRecord;
 export declare function pluralize(word: string): string;
+/**
+ * The highest NUMERIC id held by a set of records, or `0` when there is none.
+ *
+ * ONE COPY, and the duplication it replaces is the reason it lives here. Three
+ * near-identical reduces existed at once: `assignRecordId` (server-assigned id
+ * selection), `StandaloneDB.create` (src/standalone-db.ts) and the #203 test
+ * helper. `docs/improvements.md`'s standing WET Code category prescribes
+ * exactly this remedy -- extract into the module that already acts as the
+ * shared utility -- and `assignRecordId` already imported `isOrmRecord` from
+ * here.
+ *
+ * NON-NUMBERS ARE SKIPPED RATHER THAN COERCED TO `0`, AND THAT IS STYLISTIC.
+ * `StandaloneDB`'s shape mapped them to `0`, which can never beat a seed of
+ * `0`. Measured over eleven input classes (`[]`, `1`, `NaN`, `'5'`, `'abc'`,
+ * `-3`, `0`, `null`, `undefined`, `Infinity`, and mixed arrays) the two shapes
+ * produce IDENTICAL output on every one. In particular `typeof NaN` is
+ * `'number'`, so NEITHER shape coerces `NaN` -- both reject it on `NaN > max`,
+ * which is `false`. An earlier revision of this code asserted that the skip was
+ * what made the `NaN` case work; it is not, the comparison is, and that claim
+ * has been removed rather than left standing.
+ *
+ * WHAT IS LOAD-BEARING is that this is not `Math.max(...ids)`. `Math.max`
+ * returns `NaN` if any operand is `NaN`, and a record CAN be held under the key
+ * `NaN` -- so the obvious fix assigns `NaN`, lands on that slot and overwrites
+ * it, which is abofs/stonyx-orm#203 in a new disguise. Pinned by
+ * test/unit/assign-record-id-test.ts AC2; before that file existed the whole
+ * suite scored 951/0 under exactly that fix.
+ */
+export declare function maxNumericId(records: {
+    id?: unknown;
+}[]): number;
+/**
+ * The message prefix `assignRecordId` throws with when no free id can be
+ * derived for a model, and the ONE string `createHandler` matches on to answer
+ * `409` instead of letting the rejection reach express's default handler.
+ *
+ * It lives here rather than in either file because both need it and neither
+ * should own a copy: a literal in two places is how the two id coercions in
+ * orm-request.ts drifted apart (see `coerceId`). The repo has no error codes
+ * and no custom error classes -- 24 bare `throw new Error` sites across `src/`
+ * -- so a shared prefix is the narrowest way to make ONE failure distinguishable
+ * without inventing an error taxonomy this codebase does not use.
+ */
+export declare const NO_FREE_ID_ERROR = "Cannot assign record ID: no free id available";

package/dist/utils.js

@@ -15,3 +15,50 @@ export function pluralize(word) {
     }
     return basePluralize(word);
 }
+/**
+ * The highest NUMERIC id held by a set of records, or `0` when there is none.
+ *
+ * ONE COPY, and the duplication it replaces is the reason it lives here. Three
+ * near-identical reduces existed at once: `assignRecordId` (server-assigned id
+ * selection), `StandaloneDB.create` (src/standalone-db.ts) and the #203 test
+ * helper. `docs/improvements.md`'s standing WET Code category prescribes
+ * exactly this remedy -- extract into the module that already acts as the
+ * shared utility -- and `assignRecordId` already imported `isOrmRecord` from
+ * here.
+ *
+ * NON-NUMBERS ARE SKIPPED RATHER THAN COERCED TO `0`, AND THAT IS STYLISTIC.
+ * `StandaloneDB`'s shape mapped them to `0`, which can never beat a seed of
+ * `0`. Measured over eleven input classes (`[]`, `1`, `NaN`, `'5'`, `'abc'`,
+ * `-3`, `0`, `null`, `undefined`, `Infinity`, and mixed arrays) the two shapes
+ * produce IDENTICAL output on every one. In particular `typeof NaN` is
+ * `'number'`, so NEITHER shape coerces `NaN` -- both reject it on `NaN > max`,
+ * which is `false`. An earlier revision of this code asserted that the skip was
+ * what made the `NaN` case work; it is not, the comparison is, and that claim
+ * has been removed rather than left standing.
+ *
+ * WHAT IS LOAD-BEARING is that this is not `Math.max(...ids)`. `Math.max`
+ * returns `NaN` if any operand is `NaN`, and a record CAN be held under the key
+ * `NaN` -- so the obvious fix assigns `NaN`, lands on that slot and overwrites
+ * it, which is abofs/stonyx-orm#203 in a new disguise. Pinned by
+ * test/unit/assign-record-id-test.ts AC2; before that file existed the whole
+ * suite scored 951/0 under exactly that fix.
+ */
+export function maxNumericId(records) {
+    return records.reduce((max, record) => {
+        const { id } = record;
+        return typeof id === 'number' && id > max ? id : max;
+    }, 0);
+}
+/**
+ * The message prefix `assignRecordId` throws with when no free id can be
+ * derived for a model, and the ONE string `createHandler` matches on to answer
+ * `409` instead of letting the rejection reach express's default handler.
+ *
+ * It lives here rather than in either file because both need it and neither
+ * should own a copy: a literal in two places is how the two id coercions in
+ * orm-request.ts drifted apart (see `coerceId`). The repo has no error codes
+ * and no custom error classes -- 24 bare `throw new Error` sites across `src/`
+ * -- so a shared prefix is the narrowest way to make ONE failure distinguishable
+ * without inventing an error taxonomy this codebase does not use.
+ */
+export const NO_FREE_ID_ERROR = 'Cannot assign record ID: no free id available';

package/package.json

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

package/src/manage-record.ts

@@ -2,7 +2,7 @@ import Orm, { store } from '@stonyx/orm';
 import OrmRecord from './record.js';
 import { getGlobalRegistry, getPendingRegistry, getPendingBelongsToRegistry, getBelongsToRegistry, getHasManyRegistry } from './relationships.js';
 import type Serializer from './serializer.js';
-import { isOrmRecord } from './utils.js';
+import { isOrmRecord, maxNumericId, NO_FREE_ID_ERROR } from './utils.js';
 
 interface CreateRecordOptions {
   isDbRecord?: boolean;
@@ -227,9 +227,15 @@ function assignRecordId(modelName: string, rawData: { [key: string]: unknown }):
   // 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.
+  // record it never named.
+  //
+  // WHAT WIDENING THIS TO `!== undefined` ACTUALLY DOES, measured rather than
+  // asserted: `{id: ''}` early-returns, `parseInt('')` NaNs it, and the record
+  // lands on the store's `NaN` slot and OVERWRITES whatever is there — #203's
+  // own defect class. It does NOT turn access-filter-enforcement-test.ts
+  // assertion 44 red; an earlier revision of this comment claimed it did, which
+  // converted an unknown into a false assurance. AC6's BOUNDARY assertions are
+  // what catch it, and they only do so because they seed the `NaN` slot first.
   if (rawData.id || rawData.id === 0) return;
 
   // In SQL mode with numeric IDs, defer to database auto-increment.
@@ -251,59 +257,158 @@ function assignRecordId(modelName: string, rawData: { [key: string]: unknown }):
   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);
+  // ONE COPY of the max-numeric-id reduce, in src/utils.ts. There were three
+  // (here, StandaloneDB.create, and the #203 test helper) and `docs/
+  // improvements.md`'s WET Code category prescribes the extraction. What that
+  // helper must NOT be is `Math.max(...ids)`; the reason is measured and it is
+  // documented at the helper rather than duplicated here. Pinned by AC2.
+  const maxId = maxNumericId(modelStore);
 
   // 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.
+  // has run inside `serialize`. When the transform is not the identity those two
+  // differ, so a guard written as `storeMap.has(rawData.id)` checks a key the
+  // record will never occupy, misses an occupied slot and overwrites it —
+  // measured on an `uppercase`-id model: the guard checks `owner-1`, the record
+  // lands under `OWNER-1`, 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.
   //
-  // 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.
+  // THE SCOPE OF THAT CLAIM, stated rather than implied. Setting `rawData.id` to
+  // the landing key makes :50 and :69 agree for every IDEMPOTENT id transform —
+  // `number`, `float`, `string`, `passthrough`, `uppercase`, `trim`. It does NOT
+  // make them agree for `date` or `timestamp`: `transforms.date` returns a NEW
+  // object every call and a `Map` keys by identity, so `storeMap.has(landingKey)`
+  // is always `false` there and the occupancy check is vacuous. `dev` is broken
+  // for those types too — this is not a regression — but no comment here may
+  // claim a property it was not measured to have (#212 § AC5).
   //
-  // Resolved ONCE, outside the loop: `getIdType` instantiates the model class,
+  // Resolved ONCE, outside the walk: `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);
+  // DOES THIS MODEL FILE ITS RECORDS UNDER STRING KEYS? Decided by RUNNING the
+  // model's own id transform once, not by matching a type NAME against a list:
+  // `Orm.instance.transforms` (main.ts:70) is a public, MUTABLE instance
+  // property, so any enumeration of "the string-ish types" written here would be
+  // wrong the moment a consumer registers one.
+  const stringKeyed = typeof toStoreKey(maxId + 1) === 'string';
+
+  // THE CANDIDATE FOR A STRING-KEYED MODEL IS NOT A BARE NUMBER, and this is
+  // abofs/stonyx-orm#209 — which is REOPENED — not aesthetics.
+  //
+  // `orm-request.ts`'s `coerceId` (:322) resolves a NUMERIC-LOOKING string to a
+  // NUMBER on every id-bearing surface, while a model declaring
+  // `id = attr('string')` files under the STRING key. So a server-assigned `'1'`
+  // produces a record that is created and then NOT ADDRESSABLE. Measured over
+  // the route, owner store `{'1': ...}`:
+  //
+  //   GET    /owners/1       -> 404      (the record exists)
+  //   DELETE /owners/1       -> 404
+  //   GET    /owners/owner-1 -> 200
+  //
+  // and `_withHooks` (:1185) hands an after-`create` hook
+  // `context.record === undefined` for the same reason. `dev` assigned `'bob1'`,
+  // which is not numeric-looking, so `dev` has neither problem: a bare-number
+  // candidate would move #209 from "a caller supplied a numeric-looking id" onto
+  // the DEFAULT path for every server-assigned create on every string-id model.
+  // Prefixing with the model name keeps #209's population exactly as narrow as
+  // it already was, without touching the one shared coercion or the assertion
+  // that pins #209 open. Pinned by AC3.
+  const toCandidate = stringKeyed
+    ? (value: number) => `${modelName}-${value}`
+    : (value: number) => value;
+
+  // `maxId + 1` is the id AC1 pins: strictly greater than every numeric key
+  // present. IT IS NOT ALWAYS AVAILABLE, and that gap was a live denial of
+  // service. Float64 has no integer successor at or above 2^53, so
+  // `maxId + 1 === maxId` for every `maxId >= 9007199254740992` and `+ 1` inside
+  // the walk is a NO-OP there. One record filed under that key — which an
+  // unauthenticated `POST {"id":9007199254740992}` puts there, and which reaches
+  // even a filter-protected collection through has-many.ts:65 (#207), a channel
+  // GATE 0 does not cover — made the walk unable to advance, so it exhausted its
+  // budget and threw on EVERY subsequent server-assigned create, permanently,
+  // until that record was deleted. Measured over the route: 200, then 500 for
+  // every no-id create. `dev` answers 200.
+  //
+  // So a store holding one adversarial record must not disable its collection.
+  // When "above the max" is not a usable strategy the walk RESTARTS FROM 1: the
+  // store holds at most `size` keys, so one of `1 .. size + 1` is always free
+  // under an injective id transform. Pinned by AC7.
+  const start = maxId + 1;
+  let landingKey = firstFreeKey(storeMap, toStoreKey, toCandidate, start);
+
+  // THE RESTART, and it is the whole of the ceiling fix. Killing mutation:
+  // delete this block -> AC7 goes red (the route answers 409 instead of the
+  // created resource).
+  if (landingKey === NO_FREE_KEY && start !== 1) {
+    landingKey = firstFreeKey(storeMap, toStoreKey, toCandidate, 1);
+  }
+
+  if (landingKey === NO_FREE_KEY) {
+    // Reachable only with a NON-INJECTIVE id transform — see `firstFreeKey`.
+    // `createHandler` matches this message and answers 409 rather than letting it
+    // reach express's default handler, which serialises a stack trace with
+    // absolute install paths outside NODE_ENV=production (the hazard
+    // orm-request.ts:553-558 exists to name). Pinned by AC8.
+    throw new Error(`${NO_FREE_ID_ERROR} for model "${modelName}"`);
+  }
+
+  rawData.id = landingKey;
+}
+
+// Returned instead of a key so that "no key" cannot be confused with a transform
+// that legitimately produced `undefined` or `null`.
+const NO_FREE_KEY = Symbol('no free store key');
+
+/**
+ * The first store key at or above `start` that no record occupies, walking
+ * candidate ids upward, or `NO_FREE_KEY` if the walk cannot reach one.
+ */
+function firstFreeKey(
+  storeMap: Map<number | string, unknown>,
+  toStoreKey: (value: number | string) => number | string,
+  toCandidate: (value: number) => number | string,
+  start: number
+): number | string | typeof NO_FREE_KEY {
+  let candidate = start;
+  let landingKey = toStoreKey(toCandidate(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}"`);
-    }
-
+    // THE BOUND IS EXACTLY TIGHT, not conservative: this walk tries
+    // `storeMap.size + 1` DISTINCT candidates against at most `storeMap.size`
+    // occupied keys, so under an injective `toStoreKey` it provably cannot fire.
+    // Under a non-injective one it provably terminates — and that is a reachable
+    // consumer state rather than a hypothesis: `transforms.boolean`
+    // (transforms.ts:4) collapses every candidate onto `true`/`false`, and
+    // `Orm.instance.transforms` (main.ts:70) is public and MUTABLE, so a consumer
+    // can register an arbitrary non-injective transform and name it as an id
+    // type. Without this, a no-id create spins forever inside a synchronous store
+    // walk and pins a worker, which is worse than either collision policy. Its
+    // EXISTENCE and its THRESHOLD are both pinned by AC8: deleting it makes AC8
+    // HANG rather than fail, and weakening it to fire on the first collision
+    // makes AC8.1 red.
+    if (++attempts > storeMap.size) return NO_FREE_KEY;
+
+    // NOTE FOR ANYONE ADDING A SECOND EXIT HERE. A `candidate + 1 === candidate`
+    // float-saturation check was written, measured, and REMOVED: with the
+    // restart-from-1 above in place, deleting the saturation check leaves the
+    // whole suite green, because the budget reaches the same `NO_FREE_KEY` one
+    // pass later and the restart still answers. An unkillable guard in a change
+    // whose deliverable is falsifiable coverage is exactly what this story exists
+    // to stop shipping. `+ 1` being a no-op at 2^53 costs `size` extra `Map.has`
+    // calls on that one path and changes no outcome.
     candidate += 1;
-    landingKey = toStoreKey(candidate);
+    landingKey = toStoreKey(toCandidate(candidate));
   }
 
-  rawData.id = landingKey;
+  return landingKey;
 }
 
 /**
@@ -311,13 +416,47 @@ function assignRecordId(modelName: string, rawData: { [key: string]: unknown }):
  * 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 {
+function storeKeyDeriver(modelName: string): (value: number | string) => number | string {
   const idType = getIdType(modelName);
   const transform = idType ? Orm.instance?.transforms?.[idType] : undefined;
 
+  // SURVIVOR, RETAINED, with its reachability condition stated rather than left
+  // silent — `docs/project-structure.md` § "unkillable code reads as coverage and
+  // is not" is the standing rule and it applies outside orm-request.ts too.
+  //
+  // No mutation in this repo can kill this branch, and that is STRUCTURAL rather
+  // than an untested gap: `Model` declares `id = attr('number')` (model.ts:15) so
+  // every registered model has an id type; `ModelProperty` refuses a type with no
+  // registered transform (model-property.ts:4) so a declared type always
+  // resolves; and `getIdType` can therefore only return `undefined` when
+  // `getRecordClasses` yields no `modelClass` — in which case `createRecord`
+  // throws at :62 a few lines later regardless, so no record is ever filed
+  // through this branch.
+  //
+  // BECOMES REACHABLE if a model can be declared without an `id` property, if a
+  // store map can exist for a model with no registered class, or if
+  // `createRecord` stops constructing the model class. Kept rather than deleted
+  // because the alternative on that path is a `transform is not a function`
+  // TypeError, and because identity is exactly what `createRecord` would file
+  // under when no transform exists — the two agree, which is the property AC4 is
+  // about.
   if (typeof transform !== 'function') return value => value;
 
-  return value => transform(value) as number | string;
+  return value => {
+    try {
+      return transform(value) as number | string;
+    } catch {
+      // `uppercase` and `trim` (transforms.ts:11-12) call a string method on the
+      // value directly, so a NUMERIC candidate throws `value?.toUpperCase is not
+      // a function`. On `dev` they never saw one — `lastRecord.id + 1` on a
+      // string id is a string — so feeding them a number here would regress a
+      // legal, registered id type into an uncaught 500. The retry feeds the
+      // string form, which is the shape an id actually arrives in off a JSON body
+      // or a URL param. A transform that throws on BOTH shapes still propagates.
+      // Pinned by AC9.
+      return transform(String(value)) as number | string;
+    }
+  };
 }
 
 function getIdType(modelName: string): string | undefined {

package/src/orm-request.ts

@@ -185,7 +185,7 @@ import type { HookContext } from './hooks.js';
 import config from 'stonyx/config';
 import log from 'stonyx/log';
 import type { OrmRecord, AccessContext, AccessFunction, AccessMethod, AccessOperation } from './types/orm-types.js';
-import { isOrmRecord } from './utils.js';
+import { isOrmRecord, NO_FREE_ID_ERROR } from './utils.js';
 
 interface OrmRequest$ extends Request {
   protocol?: string;
@@ -762,7 +762,41 @@ export default class OrmRequest extends Request {
       // only O(1) signal that distinguishes an insert from an overwrite.
       const slotsBefore = store.get(model)?.size ?? 0;
 
-      const created = createRecord(model, recordAttributes as { [key: string]: unknown }, { serialize: false, _skipAutoPersist: true });
+      // THE ONE `createRecord` FAILURE THIS ROUTE ANSWERS RATHER THAN
+      // PROPAGATES, and it is narrow on purpose.
+      //
+      // `assignRecordId` throws when it cannot derive a free store key for a
+      // server-assigned id. Unguarded that rejection is auto-forwarded -- there
+      // is no catch here, none in @stonyx/rest-server's dispatcher
+      // (dist/request.js:41-70), and express 5 hands it to its default error
+      // handler, which serialises the STACK, with absolute install paths and the
+      // internal module graph, to an unauthenticated caller outside
+      // NODE_ENV=production. That is the hazard :553-558 already names in this
+      // file, and every sibling refusal in this handler returns an integer
+      // status instead. So this one returns 409, matching the client-duplicate
+      // refusal at :713: the caller asked for a record and the collection has no
+      // id to give it.
+      //
+      // MATCHED ON THE SHARED PREFIX, not on a literal, and NOT by catching
+      // everything: `createRecord` also throws for "ORM is not ready", a
+      // read-only view and an unregistered model store, and turning any of those
+      // into a 409 would report a configuration fault as a conflict. Anything
+      // else is re-thrown unchanged.
+      let created;
+
+      try {
+        created = createRecord(model, recordAttributes as { [key: string]: unknown }, { serialize: false, _skipAutoPersist: true });
+      } catch (error) {
+        if (!(error instanceof Error) || !error.message.startsWith(NO_FREE_ID_ERROR)) throw error;
+
+        // Not silently. A collection that can no longer assign an id is a
+        // configuration fault (a non-injective id transform), and a bare 409
+        // with no diagnostic is indistinguishable from an ordinary duplicate.
+        log.error?.(`[@stonyx/orm] ${error.message}`);
+
+        return 409; // Conflict
+      }
+
       const record = isOrmRecord(created) ? created : null;
       if (!record) return 500;
 
@@ -787,11 +821,32 @@ export default class OrmRequest extends Request {
         //
         // Both conditions are required and neither implies the other:
         //   createdNewSlot -- the store grew, so this request inserted rather
-        //                     than overwrote. Guards `assignRecordId` picking an
-        //                     id that is already taken (it returns
-        //                     last-INSERTED + 1, not max + 1, so a store whose
-        //                     insertion order is not ascending collides) -- see
-        //                     abofs/stonyx-orm#203.
+        //                     than overwrote. SURVIVOR AS OF #203, AND THAT IS
+        //                     WHAT THIS NOTE IS FOR. It used to be killable:
+        //                     `assignRecordId` returned last-INSERTED + 1, so a
+        //                     server-assigned id could land on an occupied slot,
+        //                     `createRecord` updated in place, and removing this
+        //                     half turned access-filter-enforcement-test.ts
+        //                     assertion 31 red. #203 closed that: the
+        //                     server-assigned path now walks past occupied keys,
+        //                     so no create reaching here can overwrite. Measured
+        //                     -- delete `createdNewSlot &&` below: `dev` gives
+        //                     55 pass / 1 fail with assertion 31 RED, this tree
+        //                     gives 56 pass / 0 fail, GREEN.
+        //                     KEPT ANYWAY, AND NOT FOR THE OLD REASON. Without
+        //                     it a denied create becomes `store.remove` on a key
+        //                     the caller may have influenced, which :815-820
+        //                     records as having been an unauthenticated deletion
+        //                     primitive across the whole id space. BECOMES
+        //                     KILLABLE AGAIN the moment any caller-supplied id
+        //                     can reach `createRecord` from this handler --
+        //                     which is exactly what has-many.ts:65 and
+        //                     belongs-to.ts:45 already do for ANOTHER model's
+        //                     store (abofs/stonyx-orm#207), and what a third
+        //                     un-stripped id channel would do for this one
+        //                     (#204). Do not delete it on the strength of #203
+        //                     being closed; that is the reasoning :862-867 warns
+        //                     about, one level up.
         //   identity       -- the slot still holds the object we just created,
         //                     so nothing between createRecord and here replaced
         //                     it. Deleting this half SURVIVES the suite, and it

package/src/standalone-db.ts

@@ -8,6 +8,10 @@
 
 import fs from 'fs/promises';
 import path from 'path';
+// `./utils.js` pulls in `@stonyx/utils/string` and nothing else -- no ORM
+// bootstrap, no `@stonyx/orm` index, no side effects -- so the "no framework
+// dependencies" property above still holds.
+import { maxNumericId } from './utils.js';
 
 interface StandaloneDBOptions {
   dbPath?: string;
@@ -131,12 +135,19 @@ export default class StandaloneDB {
     const records = await this.readCollection(collection);
 
     if (!data.id) {
-      const maxId = records.reduce((max, r) => {
-        const rid = typeof r.id === 'number' ? r.id : 0;
-        return rid > max ? rid : max;
-      }, 0);
-
-      data.id = maxId + 1;
+      // SHARED WITH `assignRecordId` (src/manage-record.ts), which is the other
+      // place this repo picks a server-assigned id. It was a second copy of the
+      // reduce, and nothing here pointed at it — a maintainer editing this
+      // method could not discover the other existed. See `maxNumericId` for why
+      // it is not `Math.max` (abofs/stonyx-orm#203).
+      //
+      // THE TWO ARE NOT THE SAME FUNCTION beyond this line, deliberately.
+      // `StandaloneDB` has no model, id-type or transform concept, so `maxId + 1`
+      // IS its store key; `assignRecordId` has to map the candidate through the
+      // model's declared id transform first, and then walk past occupied keys.
+      // Transplanting this method's remaining logic into the ORM reproduces
+      // #203's landing-key defect exactly — which is what AC4 pins.
+      data.id = maxNumericId(records) + 1;
     }
 
     // Check for duplicate id

package/src/utils.ts

@@ -20,3 +20,53 @@ export function pluralize(word: string): string {
 
   return basePluralize(word);
 }
+
+/**
+ * The highest NUMERIC id held by a set of records, or `0` when there is none.
+ *
+ * ONE COPY, and the duplication it replaces is the reason it lives here. Three
+ * near-identical reduces existed at once: `assignRecordId` (server-assigned id
+ * selection), `StandaloneDB.create` (src/standalone-db.ts) and the #203 test
+ * helper. `docs/improvements.md`'s standing WET Code category prescribes
+ * exactly this remedy -- extract into the module that already acts as the
+ * shared utility -- and `assignRecordId` already imported `isOrmRecord` from
+ * here.
+ *
+ * NON-NUMBERS ARE SKIPPED RATHER THAN COERCED TO `0`, AND THAT IS STYLISTIC.
+ * `StandaloneDB`'s shape mapped them to `0`, which can never beat a seed of
+ * `0`. Measured over eleven input classes (`[]`, `1`, `NaN`, `'5'`, `'abc'`,
+ * `-3`, `0`, `null`, `undefined`, `Infinity`, and mixed arrays) the two shapes
+ * produce IDENTICAL output on every one. In particular `typeof NaN` is
+ * `'number'`, so NEITHER shape coerces `NaN` -- both reject it on `NaN > max`,
+ * which is `false`. An earlier revision of this code asserted that the skip was
+ * what made the `NaN` case work; it is not, the comparison is, and that claim
+ * has been removed rather than left standing.
+ *
+ * WHAT IS LOAD-BEARING is that this is not `Math.max(...ids)`. `Math.max`
+ * returns `NaN` if any operand is `NaN`, and a record CAN be held under the key
+ * `NaN` -- so the obvious fix assigns `NaN`, lands on that slot and overwrites
+ * it, which is abofs/stonyx-orm#203 in a new disguise. Pinned by
+ * test/unit/assign-record-id-test.ts AC2; before that file existed the whole
+ * suite scored 951/0 under exactly that fix.
+ */
+export function maxNumericId(records: { id?: unknown }[]): number {
+  return records.reduce((max: number, record) => {
+    const { id } = record;
+
+    return typeof id === 'number' && id > max ? id : max;
+  }, 0);
+}
+
+/**
+ * The message prefix `assignRecordId` throws with when no free id can be
+ * derived for a model, and the ONE string `createHandler` matches on to answer
+ * `409` instead of letting the rejection reach express's default handler.
+ *
+ * It lives here rather than in either file because both need it and neither
+ * should own a copy: a literal in two places is how the two id coercions in
+ * orm-request.ts drifted apart (see `coerceId`). The repo has no error codes
+ * and no custom error classes -- 24 bare `throw new Error` sites across `src/`
+ * -- so a shared prefix is the narrowest way to make ONE failure distinguishable
+ * without inventing an error taxonomy this codebase does not use.
+ */
+export const NO_FREE_ID_ERROR = 'Cannot assign record ID: no free id available';