json-rest-api 1.0.22 → 1.0.24

package/audit/evidence/docs/schema-docs-claims-signals.txt

@@ -1,179 +0,0 @@
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:12:* **Clear Separation of Concerns:** The responsibility for *defining* types/validators is separate from the responsibility for *applying* them during validation.
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:13:* **Plugin-Based Extensibility:** New types and validators can be seamlessly added through a straightforward plugin system.
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:24:This file is the true heart and soul of the library. It acts as the central coordinator, managing the global collection of type and validator handlers, and providing the primary interface for users.
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:30:    * **Crucially, these objects are *not* directly exported.** This design choice makes them effectively "private" to the `index.js` module's scope. They serve as the single, authoritative source for all registered type casting functions and validation logic across the entire application's lifetime when this library is imported.
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:31:    * Think of them as the library's internal knowledge base for how to process different data types and apply various rules.
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:34:    * To allow external code (including plugins) to add to our `globalTypes` and `globalValidators` registries, `index.js` exports two dedicated functions: `export function addType(...)` and `export function addValidator(...)`.
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:35:    * These functions are straightforward: they take a `name` (e.g., `'string'`, `'min'`) and a `handler` function, perform a basic type check on the handler, and then assign it to the respective `globalTypes` or `globalValidators` object using the given `name` as the key.
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:39:    * The `export function use(plugin)` function is our gateway for extensibility. It expects a `plugin` object that *must* have an `install` method.
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:40:    * When `use(plugin)` is called, it executes `plugin.install()`.
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:41:    * The `use` function passes a simple API object to the plugin's `install` method: `{ addType, addValidator }`. This means the plugin only receives the specific functions it needs to register its handlers, without having to know or interact with any other internal structures. It's clean, minimal, and promotes loose coupling.
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:43:* **The Schema Factory (`createSchema`):**
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:44:    * The `const createSchema = (structure) => new Schema(structure, globalTypes, globalValidators);` function is the primary way users will interact with the library to define a new schema.
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:45:    * When you call `createSchema({ /* your schema definition */ })`, it doesn't return some intermediary manager. Instead, it directly instantiates a new `Schema` object (from `./src/Schema.js`).
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:46:    * **Crucially, it passes the *current references* to our `globalTypes` and `globalValidators` objects to the new `Schema` instance's constructor.** This means every `Schema` object created will automatically be "aware" of all the types and validators that have been registered globally up to that point.
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:48:* **The Public API (`createSchema.addType`, `createSchema.addValidator`, `createSchema.use`):**
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:49:    * For user convenience and to maintain a familiar API shape (if you've seen similar libraries), we attach the globally exported `addType`, `addValidator`, and `use` functions as properties directly onto the `createSchema` function itself:
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:51:        createSchema.addType = addType;
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:52:        createSchema.addValidator = addValidator;
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:53:        createSchema.use = use;
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:55:    * This allows consumers of the library to import just one thing (`import createSchema from 'jsonrestapi-schema';`) and then access all core functionalities through it: `createSchema(...)`, `createSchema.addType(...)`, `createSchema.use(...)`.
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:58:    * Right before the final export, `index.js` explicitly calls `createSchema.use(CorePlugin);`.
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:59:    * This ensures that as soon as your application imports `jsonrestapi-schema`, all the built-in types (like `string`, `number`, `boolean`) and validators (like `min`, `max`, `required`) are automatically registered and ready for use. No extra setup step is required for basic functionality.
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:61:### 2.2. `./src/Schema.js` - The Validation Workhorse
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:63:While `index.js` manages the global registries, the `Schema` class is where the actual validation magic happens for a *specific* schema definition.
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:65:**Key Features of `Schema.js`:**
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:67:* **Self-Contained Validation Logic:** Each instance of `Schema` represents a single, defined data structure. It contains the logic to traverse an input object, apply type casting, and run validation rules against its own `structure`.
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:68:* **Dependency Injection in Constructor:** Unlike the previous design, the `Schema` constructor (`constructor(structure, types, validators)`) now explicitly receives the `types` and `validators` registries it needs from the `createSchema` factory function. This makes its dependencies clear and improves its testability.
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:70:    1.  **Pre-checks:** Handling `required` rules, skipping fields, and dealing with `null` or empty values based on options.
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:71:    2.  **Type Casting:** It looks up the appropriate type handler from its received `this.types` registry and attempts to transform the field's value.
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:72:    3.  **Parameter Validation:** It then iterates through any validation parameters defined for the field (e.g., `min`, `max`, `validator`), looks up their respective handlers in `this.validators`, and applies them.
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:77:This file simply defines all the standard, built-in type and validator handlers that come with the library.
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:81:* **The `install` Method:** This is the critical part. As discussed, its `install` method is designed to receive the `addType` and `addValidator` functions. It then calls these functions multiple times, registering all the core functionalities like `string`, `number`, `boolean` types, and `min`, `max`, `notEmpty` validators.
-/home/merc/Development/current/json-rest-schema/ONBOARDING.md:82:* **Clear Definition of Default Handlers:** It provides well-defined functions for common data transformations and validation checks, serving as excellent examples for how to write your own custom types and validators.
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:1:# Future Migration Module: json-rest-schema-migrations
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:5:This document outlines the design and implementation plan for `json-rest-schema-migrations`, a companion package that would provide automatic differential migration generation for `json-rest-schema` schemas using Knex's database abstraction.
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:9:Earlier versions of `json-rest-schema` included helpers such as `generateKnexMigration()` to scaffold an initial table, but that functionality has since been removed from the core package. The need that sparked those helpers remains: as applications grow, schemas change — fields are added, types are modified, constraints are updated. Manually writing migration files for these changes is error-prone and time-consuming.
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:20:### 1. Schema State Management
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:32:        "email": { "type": "string", "required": true, "maxLength": 255 },
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:33:        "name": { "type": "string", "nullable": true }
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:43:import createSchema from 'json-rest-schema';
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:44:import { MigrationManager } from 'json-rest-schema-migrations';
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:55:const userSchema = createSchema({
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:56:  email: { type: 'string', required: true, maxLength: 255 },
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:57:  name: { type: 'string', nullable: false }, // Changed: was nullable
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:58:  age: { type: 'number', min: 0 },           // Added
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:63:const result = await manager.generateMigration('users', userSchema, {
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:87:  async getTableSchema(tableName) {
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:91:    // Normalize to json-rest-schema format
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:100:        type: this.mapKnexType(info.type),
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:101:        nullable: info.nullable,
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:103:        defaultTo: info.defaultValue,
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:112:    const typeMap = {
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:125:    return typeMap[dbType.toLowerCase()] || 'string';
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:130:### Phase 2: Schema Diff Engine
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:133:class SchemaDiffer {
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:134:  diff(currentSchema, targetSchema) {
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:143:    for (const [field, def] of Object.entries(targetSchema)) {
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:144:      if (!currentSchema[field]) {
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:154:    for (const [field, current] of Object.entries(currentSchema)) {
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:155:      const target = targetSchema[field];
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:168:    for (const field of Object.keys(currentSchema)) {
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:169:      if (!targetSchema[field]) {
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:172:          definition: currentSchema[field],
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:183:    const props = ['type', 'nullable', 'maxLength', 'unique', 'defaultTo'];
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:191:    if (from.type !== to.type) {
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:192:      if (from.type === 'string' && to.type === 'number') {
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:195:      if (from.type === 'number' && to.type === 'string' && to.maxLength) {
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:200:    // Nullable to required
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:201:    if (from.nullable && !to.nullable) {
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:202:      warnings.push('Making field required will fail if NULL values exist');
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:266:    // Map type
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:267:    switch (definition.type) {
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:298:    if (!definition.nullable) code += '.notNullable()';
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:300:    if (definition.defaultTo !== undefined) {
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:301:      const value = typeof definition.defaultTo === 'string'
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:302:        ? `'${definition.defaultTo}'`
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:303:        : definition.defaultTo;
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:304:      code += `.defaultTo(${value})`;
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:321:      if (change.from.nullable && !change.to.nullable) {
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:329:            type: 'error',
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:331:            message: `Cannot make field required: ${nullCount[0].count} NULL values exist`
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:336:      if (change.from.type !== change.to.type) {
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:346:          change.from.type, 
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:347:          change.to.type
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:352:            type: 'error',
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:372:const userSchema = createSchema({
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:373:  email: { type: 'string', required: true, unique: true },
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:374:  name: { type: 'string' }
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:378:await manager.createInitialMigration('users', userSchema);
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:380:// 2. Later: Add age field, make name required
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:381:const updatedSchema = createSchema({
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:382:  email: { type: 'string', required: true, unique: true },
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:383:  name: { type: 'string', required: true }, // Changed
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:384:  age: { type: 'number', min: 0 }          // Added
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:388:await manager.generateMigration('users', updatedSchema);
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:395:const plan = await manager.generateMigration('users', updatedSchema, {
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:401:  console.log(`- ${change.type}: ${change.field}`);
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:415:const result = await manager.generateMigration('products', productSchema, {
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:434:  // Schema state tracking
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:440:  // Custom type mappings
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:441:  typeMappings: {
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:476:1. Add new nullable column
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:478:3. Make it required
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:518:### 3. Schema Snapshots
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:524:const diff = await manager.compareWithSnapshot('users', userSchema);
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:558:    const oldSchema = createSchema({ email: { type: 'string' } });
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:559:    const newSchema = createSchema({ 
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:560:      email: { type: 'string' },
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:561:      age: { type: 'number' }
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:564:    const changes = await manager.detectChanges('users', newSchema);
-/home/merc/Development/current/json-rest-schema/FUTURE_MIGRATION_MODULE.md:587:This migration module would significantly enhance the json-rest-schema ecosystem by providing:
-/home/merc/Development/current/json-rest-schema/README.md:1:# How to Use the Schema Validation Library: A Tutorial
-/home/merc/Development/current/json-rest-schema/README.md:5:## 1. Getting Started: Your First Schema
-/home/merc/Development/current/json-rest-schema/README.md:12:import createSchema from './src/index.js';
-/home/merc/Development/current/json-rest-schema/README.md:15:const userSchema = createSchema({
-/home/merc/Development/current/json-rest-schema/README.md:16:  username: { type: 'string', required: true, minLength: 3 },
-/home/merc/Development/current/json-rest-schema/README.md:17:  email: { type: 'string', required: true },
-/home/merc/Development/current/json-rest-schema/README.md:18:  age: { type: 'number', min: 18, defaultTo: 18 }
-/home/merc/Development/current/json-rest-schema/README.md:34:  const { validatedObject, errors } = await userSchema.validate(userInput);
-/home/merc/Development/current/json-rest-schema/README.md:51:1.  The `age` string `'25'` is **cast** to the number `25` by the `number` type handler.
-/home/merc/Development/current/json-rest-schema/README.md:52:2.  The `username` string `'  alex '` is **transformed** by the `string` type handler to `'alex'` (it gets trimmed).
-/home/merc/Development/current/json-rest-schema/README.md:78:  // email is missing, fails 'required: true'
-/home/merc/Development/current/json-rest-schema/README.md:82:const { validatedObject, errors } = await userSchema.validate(invalidInput);
-/home/merc/Development/current/json-rest-schema/README.md:100:    "message": "Field is required",
-/home/merc/Development/current/json-rest-schema/README.md:114:* **`params`**: Extra context about the failure. This is incredibly useful for creating dynamic error messages (e.g., "You entered 2 characters, but a minimum of 3 is required.").
-/home/merc/Development/current/json-rest-schema/README.md:120:Here is a complete list of all types and validators available out of the box.
-/home/merc/Development/current/json-rest-schema/README.md:124:A field's `type` defines how the input value will be converted before any other validation rules are run.
-/home/merc/Development/current/json-rest-schema/README.md:139:| `none` | The "identity" type. Passes the value through completely unchanged without any casting. |
-/home/merc/Development/current/json-rest-schema/README.md:143:Validators are rules that run after a value has been cast to its proper type.
-/home/merc/Development/current/json-rest-schema/README.md:147:| `required: true` | The field must be present in the input object. Fails if the key is `undefined`. |
-/home/merc/Development/current/json-rest-schema/README.md:148:| `minLength: <number>` | For `string` types, validates the minimum character length. |
-/home/merc/Development/current/json-rest-schema/README.md:149:| `maxLength: <number>` | For `string` types, validates the maximum character length. |
-/home/merc/Development/current/json-rest-schema/README.md:150:| `min: <number>` | For `number` types, validates the minimum value. |
-/home/merc/Development/current/json-rest-schema/README.md:151:| `max: <number>` | For `number` types, validates the maximum value. |
-/home/merc/Development/current/json-rest-schema/README.md:152:| `notEmpty: true` | The field cannot be an empty string (`''`). This is different from `required`, as an empty string is still a defined value. |
-/home/merc/Development/current/json-rest-schema/README.md:153:| `length: <number>`| For `string` types, it **truncates** the string to the specified length. For `number` types, it throws an error if the number of digits in the original input exceeds the specified length. |
-/home/merc/Development/current/json-rest-schema/README.md:154:| `nullable: true`| Allows the value for this field to be `null`. By default, `null` is not allowed. |
-/home/merc/Development/current/json-rest-schema/README.md:155:| `nullOnEmpty: true`| If the input value is an empty string (`''`), it will be cast to `null` before other validators run. |
-/home/merc/Development/current/json-rest-schema/README.md:158:| `validator: <function>`| Allows you to provide your own custom validation function for complex, one-off logic. |
-/home/merc/Development/current/json-rest-schema/README.md:159:| `defaultTo: <value>` | If the field is not present in the input object and the entire object is valid, this value will be used. Can be a value or a function that returns a value. |
-/home/merc/Development/current/json-rest-schema/README.md:160:| `unsigned: true` | For `number` and `id` types, indicates the value should be non-negative (database hint). |
-/home/merc/Development/current/json-rest-schema/README.md:161:| `precision: <number>` | For `number` types, total number of digits (database hint for decimal types). |
-/home/merc/Development/current/json-rest-schema/README.md:162:| `scale: <number>` | For `number` types, number of decimal places (database hint for decimal types). |
-/home/merc/Development/current/json-rest-schema/README.md:171:The real power of the library comes from its extensibility. You can easily add your own reusable types and validators. When you do this, you'll be passed a powerful `context` object.
-/home/merc/Development/current/json-rest-schema/README.md:175:Every custom type and validator handler receives a `context` object as its only argument. This object is your toolbox, giving you all the information you need to perform complex logic. Here are its properties:
-/home/merc/Development/current/json-rest-schema/README.md:177:* **`value`**: The current value of the field being processed. Be aware that this value may have already been changed by the type handler or a previous validator.
-/home/merc/Development/current/json-rest-schema/README.md:180:* **`valueBeforeCast`**: The original, raw value for the field, exactly as it was in the input object before any type casting occurred.
-/home/merc/Development/current/json-rest-schema/README.md:182:* **`definition`**: The schema definition object for the current field. For a field defined as `{ type: 'string', min: 5 }`, this would be that exact object.
-/home/merc/Development/current/json-rest-schema/README.md:183:* **`parameterName`**: *(For validators only)* The name of the validation rule currently being executed (e.g., `'min'`).
-/home/merc/Development/current/json-rest-schema/README.md:184:* **`parameterValue`**: *(For validators only)* The value of the validation rule currently being executed (e.g., the `5` in `min: 5`).
-/home/merc/Development/current/json-rest-schema/README.md:185:* **`throwTypeError()`**: A function you can call to throw a standardized `TYPE_CAST_FAILED` error. This is the preferred way to report an error from within a type handler.
-/home/merc/Development/current/json-rest-schema/README.md:186:* **`throwParamError(code, message, params)`**: A function you can call to throw a standardized validation error from within a validator. It accepts a custom error `code`, a `message`, and an optional `params` object.
-/home/merc/Development/current/json-rest-schema/README.md:192:You can define a new validator once and use it anywhere.
-/home/merc/Development/current/json-rest-schema/README.md:196:createSchema.addValidator('slug', (context) => {
-/home/merc/Development/current/json-rest-schema/README.md:199:  if (typeof context.value !== 'string' || !slugRegex.test(context.value)) {
-/home/merc/Development/current/json-rest-schema/README.md:209:const articleSchema = createSchema({
-/home/merc/Development/current/json-rest-schema/README.md:210:  title: { type: 'string', required: true },
-/home/merc/Development/current/json-rest-schema/README.md:211:  slug: { type: 'string', required: true, slug: true } // Use it here
-/home/merc/Development/current/json-rest-schema/README.md:217:A `Type` is used for casting. Imagine you want a `csv` type that takes a string like `"apple,banana,cherry"` and turns it into an array `['apple', 'banana', 'cherry']`.
-/home/merc/Development/current/json-rest-schema/README.md:221:createSchema.addType('csv', (context) => {
-/home/merc/Development/current/json-rest-schema/README.md:225:  if (typeof context.value !== 'string') {
-/home/merc/Development/current/json-rest-schema/README.md:226:    // Use the public context method to throw a standardized type error
-/home/merc/Development/current/json-rest-schema/README.md:233:// Now use your new 'csv' type
-/home/merc/Development/current/json-rest-schema/README.md:234:const productSchema = createSchema({
-/home/merc/Development/current/json-rest-schema/README.md:235:  name: { type: 'string', required: true },
-/home/merc/Development/current/json-rest-schema/README.md:236:  tags: { type: 'csv' }
-/home/merc/Development/current/json-rest-schema/README.md:240:const { validatedObject } = await productSchema.validate(product);
-/home/merc/Development/current/json-rest-schema/README.md:250:If you create a lot of custom types and validators for your project, you can bundle them into a single, reusable **Plugin**. A plugin is just an object with an `install` method.
-/home/merc/Development/current/json-rest-schema/README.md:253:// my-custom-plugin.js
-/home/merc/Development/current/json-rest-schema/README.md:258:        if (typeof context.value !== 'string') context.throwTypeError();
-/home/merc/Development/current/json-rest-schema/README.md:264:        if (typeof context.value !== 'string' || !slugRegex.test(context.value)) {
-/home/merc/Development/current/json-rest-schema/README.md:274:import createSchema from './src/index.js';
-/home/merc/Development/current/json-rest-schema/README.md:275:import MyCustomPlugin from './my-custom-plugin.js';
-/home/merc/Development/current/json-rest-schema/README.md:278:createSchema.use(MyCustomPlugin);
-/home/merc/Development/current/json-rest-schema/README.md:281:const mySchema = createSchema({
-/home/merc/Development/current/json-rest-schema/README.md:282:  tags: { type: 'csv' },
-/home/merc/Development/current/json-rest-schema/README.md:283:  pageUrl: { type: 'string', slug: true }
-/home/merc/Development/current/json-rest-schema/README.md:293:`json-rest-schema` is deliberately scoped to runtime validation and transformation. It no longer ships helpers for creating database tables or migrations, and it does not prescribe a specific persistence layer. Treat the schemas you build with this library as the canonical description of your data when you design storage models, migrations, API responses, or documentation.
-/home/merc/Development/current/json-rest-schema/README.md:295:If you pair the library with a database toolkit (such as Knex), keep the tooling concerns separate: write migrations and models in the tool that best fits your project, then reuse the same field definitions inside `createSchema` so validation, casting, and persistence stay aligned.

package/audit/evidence/external/corpus-freeze.md

@@ -1,21 +0,0 @@
-# External Corpus Freeze
-
-Frozen on: 2026-03-01T15:38:04Z
-
-## Standards Corpus (for M6 scoring)
-- JSON:API specification (latest stable): https://jsonapi.org/format/
-- HTTP Semantics (RFC 9110): https://www.rfc-editor.org/rfc/rfc9110
-- HTTP PATCH method (RFC 5789): https://www.rfc-editor.org/rfc/rfc5789
-- CORS protocol reference (Fetch / MDN references used as operational interpretation)
-
-## Competitor Corpus (for M6 benchmarking)
-- json-api-serializer (npm + repository docs)
-- @jsonapi/server (repository/docs)
-- fortune.js (docs/repo)
-- NestJS ecosystem patterns for JSON:API integration
-- Modern API framework comparison points (Express/Nest/Fastify patterns where relevant)
-
-## Freeze Rules
-- Scoring criteria and comparator set are fixed before scoring.
-- Additional sources may be appended only for evidence depth, not to change scoring dimensions.
-- All scored external claims must cite source links in audit/evidence/external/.

package/audit/evidence/external/npm-competitor-metadata.txt

@@ -1,70 +0,0 @@
-# Comparator package metadata (npm view)
-captured_at=2026-03-01T16:01:15Z
-
-## jsonapi-serializer
-{
-  "name": "jsonapi-serializer",
-  "version": "3.6.9",
-  "description": "A Node.js framework agnostic library for serializing your data to JSON API",
-  "license": "MIT",
-  "repository.url": "git+https://github.com/SeyZ/jsonapi-serializer.git",
-  "homepage": "https://github.com/SeyZ/jsonapi-serializer#readme",
-  "dist-tags.latest": "3.6.9",
-  "time.modified": "2026-01-16T16:48:39.205Z"
-}
-
-## json-api-serializer
-{
-  "name": "json-api-serializer",
-  "version": "2.6.6",
-  "description": "Framework agnostic JSON API serializer.",
-  "license": "MIT",
-  "repository.url": "git+https://github.com/danivek/json-api-serializer.git",
-  "homepage": "https://github.com/danivek/json-api-serializer#readme",
-  "dist-tags.latest": "2.6.6",
-  "time.modified": "2022-06-19T06:11:18.322Z"
-}
-
-## @jsonapi/server
-{
-  "error": {
-    "code": "E404",
-    "summary": "Not Found - GET https://registry.npmjs.org/@jsonapi%2fserver - Not found",
-    "detail": "The requested resource '@jsonapi/server@*' could not be found or you do not have permission to access it.\n\nNote that you can also install from a\ntarball, folder, http url, or git url."
-  }
-}
-not_found
-
-## fortune
-{
-  "name": "fortune",
-  "version": "5.5.19",
-  "description": "Non-native graph database abstraction layer for Node.js and web browsers.",
-  "license": "MIT",
-  "repository.url": "git+ssh://git@github.com/fortunejs/fortune.git",
-  "homepage": "http://fortune.js.org",
-  "dist-tags.latest": "5.5.19",
-  "time.modified": "2024-02-20T22:41:33.598Z"
-}
-
-## @tqman/nestjs-json-api
-{
-  "error": {
-    "code": "E404",
-    "summary": "Not Found - GET https://registry.npmjs.org/@tqman%2fnestjs-json-api - Not found",
-    "detail": "The requested resource '@tqman/nestjs-json-api@*' could not be found or you do not have permission to access it.\n\nNote that you can also install from a\ntarball, folder, http url, or git url."
-  }
-}
-not_found
-
-## nestjs-json-api
-{
-  "name": "nestjs-json-api",
-  "version": "1.1.5",
-  "description": "A library to implement a JSON API in NestJs",
-  "license": "MIT",
-  "homepage": "https://github.com/makmonty/nestjs-json-api",
-  "dist-tags.latest": "1.1.5",
-  "time.modified": "2022-05-10T12:47:31.673Z"
-}
-

package/audit/evidence/external/npm-download-signals.txt

@@ -1,23 +0,0 @@
-# npm download signals (last-month)
-captured_at=2026-03-01T16:03:15Z
-
-## jsonapi-serializer
-{"downloads":326010,"start":"2026-01-30","end":"2026-02-28","package":"jsonapi-serializer"}
-
-## json-api-serializer
-{"downloads":243752,"start":"2026-01-30","end":"2026-02-28","package":"json-api-serializer"}
-
-## jsonapi-server
-{"downloads":1526,"start":"2026-01-30","end":"2026-02-28","package":"jsonapi-server"}
-
-## fortune
-{"downloads":10453,"start":"2026-01-30","end":"2026-02-28","package":"fortune"}
-
-## nestjs-json-api
-{"downloads":15,"start":"2026-01-30","end":"2026-02-28","package":"nestjs-json-api"}
-
-## @jsonapi-serde/server
-{"downloads":221,"start":"2026-01-30","end":"2026-02-28","package":"@jsonapi-serde/server"}
-
-## @yaser2us/json-api-nestjs
-{"downloads":20,"start":"2026-01-30","end":"2026-02-28","package":"@yaser2us/json-api-nestjs"}

package/audit/evidence/external/npm-jsonapi-server.txt

@@ -1,8 +0,0 @@
-{
-  "name": "jsonapi-server",
-  "version": "4.2.0",
-  "description": "A config driven NodeJS framework implementing json:api",
-  "repository.url": "git+https://github.com/holidayextras/jsonapi-server.git",
-  "homepage": "https://github.com/holidayextras/jsonapi-server#readme",
-  "time.modified": "2022-06-19T06:35:25.049Z"
-}

package/audit/evidence/external/npm-modern-jsonapi-metadata.txt

@@ -1,38 +0,0 @@
-# Additional modern JSON:API toolkit metadata
-captured_at=2026-03-01T16:02:41Z
-
-## @jsonapi-serde/server
-{
-  "name": "@jsonapi-serde/server",
-  "version": "1.5.1",
-  "description": "Framework agnostic JSON:API serialization and deserialization",
-  "license": "BSD-3-Clause",
-  "repository.url": "git+https://github.com/DASPRiD/jsonapi-serde-js.git",
-  "homepage": "https://github.com/DASPRiD/jsonapi-serde-js#readme",
-  "dist-tags.latest": "1.5.1",
-  "time.modified": "2026-02-14T18:21:28.135Z"
-}
-
-## @jsonapi-serde/openapi
-{
-  "name": "@jsonapi-serde/openapi",
-  "version": "1.4.1",
-  "description": "OpenAPI schema generation for JSON:API serde",
-  "license": "BSD-3-Clause",
-  "repository.url": "git+https://github.com/DASPRiD/jsonapi-serde-js.git",
-  "homepage": "https://github.com/DASPRiD/jsonapi-serde-js#readme",
-  "dist-tags.latest": "1.4.1",
-  "time.modified": "2026-02-14T18:21:37.816Z"
-}
-
-## @yaser2us/json-api-nestjs
-{
-  "name": "@yaser2us/json-api-nestjs",
-  "version": "10.0.0-beta.10",
-  "description": "JsonApi Plugin for NestJs",
-  "license": "MIT",
-  "repository.url": "git+https://github.com/yaser2us/nestjs-json-api.git",
-  "homepage": "https://github.com/yaser2us/nestjs-json-api#readme",
-  "dist-tags.latest": "10.0.0-beta.10",
-  "time.modified": "2025-06-18T09:28:14.604Z"
-}

package/audit/evidence/external/readme-fortune-signals.txt

@@ -1,26 +0,0 @@
-7:Fortune.js is a non-native graph [database abstraction layer](https://en.wikipedia.org/wiki/Database_abstraction_layer) that implements graph-like features on the application-level for Node.js and web browsers. It provides a common interface for databases, as well as relationships, inverse updates, referential integrity, which are built upon assumptions in the data model.
-11:- Bi-directional relationships in any database.
-13:- Sharing the same data models on the server and client.
-21:*This is the core module. Additional features such as networking (HTTP, WebSocket), database adapters, serialization formats are listed in the [plugins page](http://fortune.js.org/plugins).*
-26:Only record type definitions need to be provided. These definitions describe what data types may belong on a record and what relationships they may have, for which Fortune.js does inverse updates and maintains referential integrity. Here's an example of a basic micro-blogging service:
-39:    // Many-to-one relationship of user posts to post author.
-45:    // One-to-many relationship of post author to user posts.
-51:Note that the primary key `id` is reserved, so there is no need to specify this. Links are `id`s that are maintained internally at the application-level by Fortune.js, and are always denormalized so that every link has a back-link. What this also means is that changes in a record will affect the links in related records.
-53:By default, the data is persisted in memory (and IndexedDB for the browser). There are adapters for databases such as [MongoDB](https://github.com/fortunejs/fortune-mongodb), [Postgres](https://github.com/fortunejs/fortune-postgres), and [NeDB](https://github.com/fortunejs/fortune-nedb). See the [plugins page](http://fortune.js.org/plugins/) for more details.
-59:// argument is used for finding related records in the same request and is
-61:// the adapter. All methods return promises.
-63:store.create(type, records, include, meta) // Records required.
-104:Based on whether or not the resolved record is different from what was passed in, serializers may decide not to show the resolved record of the output hook for update and delete requests.
-122:There is a [HTTP listener implementation](https://github.com/fortunejs/fortune-http), which returns a Node.js request listener that may be composed within larger applications. It maps Fortune requests and responses to the HTTP protocol automatically:
-125:// Bring your own HTTP! This makes it easier to add SSL and allows the user to
-126:// choose between different HTTP implementations, such as HTTP/2.
-129:const fortuneHTTP = require('fortune-http')
-133:// The `fortuneHTTP` function returns a listener function which does
-134:// content negotiation, and maps the internal response to a HTTP response.
-135:const listener = fortuneHTTP(store)
-136:const server = http.createServer((request, response) =>
-140:store.connect().then(() => server.listen(1337))
-143:This yields an *ad hoc* JSON over HTTP API, as well as a HTML interface for humans. There are also serializers for [Micro API](https://github.com/fortunejs/fortune-micro-api) (JSON-LD) and [JSON API](https://github.com/fortunejs/fortune-json-api).
-150:- Inverse relationship updates, automatically maintain both sides of relationships between records.
-151:- Referential integrity, ensure that links must be valid at the application level.
-153:- Adapter interface, use any database that can implement an adapter.

package/audit/evidence/external/readme-fortune.md

@@ -1,165 +0,0 @@
-# [![Fortune.js](https://fortunejs.github.io/fortune/assets/fortune_logo.svg)](http://fortune.js.org)
-
-[![Build Status](https://img.shields.io/travis/fortunejs/fortune/master.svg?style=flat-square)](https://travis-ci.org/fortunejs/fortune)
-[![npm Version](https://img.shields.io/npm/v/fortune.svg?style=flat-square)](https://www.npmjs.com/package/fortune)
-[![License](https://img.shields.io/npm/l/fortune.svg?style=flat-square)](https://raw.githubusercontent.com/fortunejs/fortune/master/LICENSE)
-
-Fortune.js is a non-native graph [database abstraction layer](https://en.wikipedia.org/wiki/Database_abstraction_layer) that implements graph-like features on the application-level for Node.js and web browsers. It provides a common interface for databases, as well as relationships, inverse updates, referential integrity, which are built upon assumptions in the data model.
-
-It's particularly useful for:
-
-- Bi-directional relationships in any database.
-- Applications that need storage options to be portable.
-- Sharing the same data models on the server and client.
-
-[View the website](http://fortune.js.org) for documentation. Get it from `npm`:
-
-```sh
-$ npm install fortune --save
-```
-
-*This is the core module. Additional features such as networking (HTTP, WebSocket), database adapters, serialization formats are listed in the [plugins page](http://fortune.js.org/plugins).*
-
-
-## Usage
-
-Only record type definitions need to be provided. These definitions describe what data types may belong on a record and what relationships they may have, for which Fortune.js does inverse updates and maintains referential integrity. Here's an example of a basic micro-blogging service:
-
-```js
-const fortune = require('fortune') // Works in web browsers, too.
-
-const store = fortune({
-  user: {
-    name: String,
-
-    // Following and followers are inversely related (many-to-many).
-    following: [ Array('user'), 'followers' ],
-    followers: [ Array('user'), 'following' ],
-
-    // Many-to-one relationship of user posts to post author.
-    posts: [ Array('post'), 'author' ]
-  },
-  post: {
-    message: String,
-
-    // One-to-many relationship of post author to user posts.
-    author: [ 'user', 'posts' ]
-  }
-})
-```
-
-Note that the primary key `id` is reserved, so there is no need to specify this. Links are `id`s that are maintained internally at the application-level by Fortune.js, and are always denormalized so that every link has a back-link. What this also means is that changes in a record will affect the links in related records.
-
-By default, the data is persisted in memory (and IndexedDB for the browser). There are adapters for databases such as [MongoDB](https://github.com/fortunejs/fortune-mongodb), [Postgres](https://github.com/fortunejs/fortune-postgres), and [NeDB](https://github.com/fortunejs/fortune-nedb). See the [plugins page](http://fortune.js.org/plugins/) for more details.
-
-Fortune has 4 main methods: `find`, `create`, `update`, & `delete`, which correspond to [CRUD](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete). The method signatures are as follows:
-
-```js
-// The first argument `type` is always required. The optional `include`
-// argument is used for finding related records in the same request and is
-// documented in the `request` method, and the optional `meta` is specific to
-// the adapter. All methods return promises.
-store.find(type, ids, options, include, meta)
-store.create(type, records, include, meta) // Records required.
-store.update(type, updates, include, meta) // Updates required.
-store.delete(type, ids, include, meta)
-
-// For example...
-store.find('user', 123).then(results => { ... })
-```
-
-The first method call to interact with the database will trigger a connection to the data store, and it returns the result as a Promise. The specific methods wrap around the more general `request` method, see the [API documentation for `request`](http://fortune.js.org/api/#fortune-request).
-
-
-## Input and Output Hooks
-
-I/O hooks isolate business logic, and are part of what makes the interface reusable across different protocols. An input and output hook function may be defined per record type. Hook functions accept at least two arguments, the `context` object, the `record`, and optionally the `update` object for an `update` request. The method of an input hook may be any method except `find`, and an output hook may be applied on all methods.
-
-An input hook function may optionally return or resolve a value to determine what gets persisted, and it is safe to mutate any of its arguments. The returned or resolved value must be the record if it's a create request, the update if it's an update request, or anything (or simply `null`) if it's a delete request. For example, an input hook function for a record may look like this:
-
-```js
-function input (context, record, update) {
-  switch (context.request.method) {
-    // If it's a create request, return the record.
-    case 'create': return record
-
-    // If it's an update request, return the update.
-    case 'update': return update
-
-    // If it's a delete request, the return value doesn't matter.
-    case 'delete': return null
-  }
-}
-```
-
-An output hook function may optionally return or resolve a record, and it is safe to mutate any of its arguments.
-
-```js
-function output (context, record) {
-  record.accessedAt = new Date()
-  return record
-}
-```
-
-Based on whether or not the resolved record is different from what was passed in, serializers may decide not to show the resolved record of the output hook for update and delete requests.
-
-Hooks for a record type may be defined as follows:
-
-```js
-const store = fortune({
-  user: { ... }
-}, {
-  hooks: {
-    // Hook functions must be defined in order: input first, output last.
-    user: [ input, output ]
-  }
-})
-```
-
-
-## Networking
-
-There is a [HTTP listener implementation](https://github.com/fortunejs/fortune-http), which returns a Node.js request listener that may be composed within larger applications. It maps Fortune requests and responses to the HTTP protocol automatically:
-
-```js
-// Bring your own HTTP! This makes it easier to add SSL and allows the user to
-// choose between different HTTP implementations, such as HTTP/2.
-const http = require('http')
-const fortune = require('fortune')
-const fortuneHTTP = require('fortune-http')
-
-const store = fortune(...)
-
-// The `fortuneHTTP` function returns a listener function which does
-// content negotiation, and maps the internal response to a HTTP response.
-const listener = fortuneHTTP(store)
-const server = http.createServer((request, response) =>
-  listener(request, response)
-  .catch(error => { /* error logging */ }))
-
-store.connect().then(() => server.listen(1337))
-```
-
-This yields an *ad hoc* JSON over HTTP API, as well as a HTML interface for humans. There are also serializers for [Micro API](https://github.com/fortunejs/fortune-micro-api) (JSON-LD) and [JSON API](https://github.com/fortunejs/fortune-json-api).
-
-Fortune.js implements its own [wire protocol](https://github.com/fortunejs/fortune-ws) based on [WebSocket](https://developer.mozilla.org/docs/Web/API/WebSockets_API) and [MessagePack](http://msgpack.org), which is useful for soft real-time applications.
-
-
-## Features and Non-Features
-
-- Inverse relationship updates, automatically maintain both sides of relationships between records.
-- Referential integrity, ensure that links must be valid at the application level.
-- Type validations, fields are guaranteed to belong to a single type.
-- Adapter interface, use any database that can implement an adapter.
-- **No** object-relational mapping (ORM) or active record pattern, just plain data objects.
-- **No** coupling with network protocol, handle requests from anywhere.
-
-
-## Requirements
-
-Fortune.js is written in ECMAScript 5.1, with one ECMAScript 6 addition: **Promise**. Most of its public API returns Promises to be compatible with future editions of the language.
-
-
-## License
-
-This software is licensed under the [MIT license](https://raw.githubusercontent.com/fortunejs/fortune/master/LICENSE).