# Lens: Defense-in-Depth

Analyze the code for "Structural Impossibility" of bugs. Look for validation at every layer data passes through.

## The 4 Layers of Validation

Check if the code implements validation at these 4 layers. **Flag missing layers as issues.**

### 1. Entry Point Validation
*   **Check:** Does the public API/CLI/Controller reject invalid input immediately?
*   **Flag:** Functions that assume input is valid because "the UI checks it" or "the caller checks it".
*   **Fix:** Add schemas (Zod/Pydantic) or explicit guards at the boundary.

### 2. Business Logic Validation
*   **Check:** Does the core domain logic ensure state consistency?
*   **Flag:** Operations that could put entities into invalid states if called directly (bypassing controllers).
*   **Fix:** Invariants in the domain model / entity classes.

### 3. Environment Guards (Safety)
*   **Check:** Are destructive operations checked against the environment?
*   **Flag:** `dropDatabase()`, `rm -rf`, or mass-email logic that runs without checking `NODE_ENV` or `PROD` flags.
*   **Fix:** Explicit checks: `if (isProd && !force) throw Error(...)`.

### 4. Debug Instrumentation (Forensics)
*   **Check:** When things fail, is there enough context to know *why*?
*   **Flag:** `catch (e) { return null }` (Swallowed errors).
*   **Fix:** Log the stack, inputs, and context before handling.

## Structural Redundancy

*   **Principle:** "The bug should be structurally impossible."
*   **Flag:** Any code where a single bug in a caller could cause data corruption in the callee.
*   **Fix:** "Trust but verify" - validate inputs even in internal private methods if the consequence is high.
