Core Invariants Architecture Rules

Invariant 1: The in & local Parameter Convention

Every internal function in the engine strictly accepts a single configuration object with in-prefixed keys, and immediately assigns each key to an immutable local-prefixed constant:

// CORRECT: Adheres to KeshavSoft convention
const startFunc = ({ inSource, inRecipe }) => {
    const localSource = inSource;
    const localRecipe = inRecipe;

    // Use ONLY localSource and localRecipe below
    if (Array.isArray(localSource)) {
        return traverseArray({ inItems: localSource, inRecipe: localRecipe });
    }

    if (typeof localSource === "object" && localSource !== null) {
        return traverseObject({ inSource: localSource, inRecipe: localRecipe });
    }

    return localSource;
};

// VIOLATION: Never use naked positional parameters
function startFunc(source, recipe) { ... }

Rationale:

• Prevents parameter re-assignment bugs.
• Enforces immutability at the function boundary.
• Standardizes internal stack traces and function signatures across the entire repository.

Invariant 2: Absolute Source Immutability

inSource belongs to the external Data Provider. It must never be mutated, altered, or augmented in place. The transformed result is constructed fresh as a new object or array.

Invariant 3: Zero Runtime Dependencies

The engine is written in standard ES modules without third-party dependencies (no lodash, ramda, or custom AST parsers).

Benefits: Zero security vulnerability surface, instant browser bundle loading, and universal execution across Node.js, Bun, Deno, and web browsers.

Invariant 4: Zero Code Comments in Core Engine

Code intent is communicated purely through file/directory hierarchy (traverseObject, traverseArray, ifTransformFound) and explicit variable naming. If logic seems complicated enough to require a comment, it must be refactored into a clear, dedicated submodule.