infinity — Input Boundary & Validation Protocol

Core Philosophy

Nothing untrusted ever reaches the core — it is stopped before contact. No external data touches the codebase raw. Every boundary where data enters the system must have a filter.

The #1 source of silent bugs, crashes, and vulnerabilities is external data that arrives in an unexpected shape and gets used directly without checking. This skill enforces a filter layer at every entry point, every time.

When to Use This Skill

• Use when you need to handle an API response
• Use when reading user input or adding a form handler
• Use when working with environment variables or CLI arguments
• Use when parsing webhooks or reading from the filesystem
• Use when any code calls .body, .params, .query, .env, fs.read, or a third-party SDK response

The Four Phases

PHASE 1 — Boundary Detection

Before writing or modifying any code that involves external data, the AI must identify and list every entry point in scope:

• HTTP request bodies, headers, query params
• User form inputs and UI-submitted data
• Environment variables and config files
• Third-party API responses
• Webhook payloads
• File reads from disk
• CLI arguments
• Database query results from external sources
• WebSocket messages

The AI must not write any data-handling logic until every entry point in scope is listed.

PHASE 2 — Classify Each Input

For every entry point identified, the AI classifies it into one of three trust levels:

Rule: TRUSTED inputs may be used directly. SEMI-TRUSTED and UNTRUSTED inputs must pass through a filter layer before any use.

The AI outputs this classification before writing any handling code:

INFINITY — BOUNDARY MAP
─────────────────────────────────────────
Entry Point              | Trust Level  | Filter Required
─────────────────────────────────────────
req.body.email           | UNTRUSTED    | ✓ format + sanitize
process.env.API_KEY      | UNTRUSTED    | ✓ presence + non-empty
internalService.getData()| SEMI-TRUSTED | ✓ schema validate
PAGINATION_LIMIT = 20    | TRUSTED      | ✗ none needed
─────────────────────────────────────────

PHASE 3 — Mandatory Filter Layer

Every UNTRUSTED and SEMI-TRUSTED input must pass through validation before it reaches any business logic, storage, or rendering. The AI must apply the right filter type for the right context:

Type Checking

• Verify the input is the expected type before using it
• Never assume a string is a string, a number is a number, or an array is an array

Schema Validation

• For objects and API responses, validate shape before accessing nested fields
• If a required field is missing, reject — do not use a fallback that hides the problem

Sanitization

• Strip or escape content before rendering to UI (prevent XSS)
• Normalize strings before storage (trim whitespace, consistent casing where appropriate)

Presence & Format Checks

• Env vars: must exist and be non-empty before use
• IDs and tokens: must match expected format before use

Rejection Rule

• On invalid input: reject explicitly and return a clear error
• Never silently use bad data with a fallback
• Never let bad data pass through to fix itself "downstream"

// WRONG — using raw input directly
const user = await db.find(req.params.id);

// RIGHT — validate before use
const id = req.params.id;
if (!id || typeof id !== 'string' || !isValidUUID(id)) {
  return res.status(400).json({ error: 'Invalid ID format' });
}
const user = await db.find(id);

PHASE 4 — Self-Check Before Done

Before the AI declares any data-handling code complete, it traces each entry point and confirms:

INFINITY — VERIFICATION
─────────────────────────────────────────
Entry Point              | Filter Exists | Filter Type
─────────────────────────────────────────
req.body.email           | ✓ YES         | format + sanitize

…