home / skills / secondsky / claude-skills / defense-in-depth-validation

This skill enforces defense-in-depth validation across all data layers, preventing bugs by validating at entry, business logic, environment, and debugging

npx playbooks add skill secondsky/claude-skills --skill defense-in-depth-validation

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
3.8 KB
---
name: defense-in-depth-validation
description: Validate at every layer data passes through to make bugs impossible. Use when invalid data causes failures deep in execution, requiring validation at multiple system layers.
version: 1.1.0
---

# Defense-in-Depth Validation

## Overview

When you fix a bug caused by invalid data, adding validation at one place feels sufficient. But that single check can be bypassed by different code paths, refactoring, or mocks.

**Core principle:** Validate at EVERY layer data passes through. Make the bug structurally impossible.

## Why Multiple Layers

Single validation: "We fixed the bug"
Multiple layers: "We made the bug impossible"

Different layers catch different cases:
- Entry validation catches most bugs
- Business logic catches edge cases
- Environment guards prevent context-specific dangers
- Debug logging helps when other layers fail

## The Four Layers

### Layer 1: Entry Point Validation
**Purpose:** Reject obviously invalid input at API boundary

```typescript
function createProject(name: string, workingDirectory: string) {
  if (!workingDirectory || workingDirectory.trim() === '') {
    throw new Error('workingDirectory cannot be empty');
  }
  if (!existsSync(workingDirectory)) {
    throw new Error(`workingDirectory does not exist: ${workingDirectory}`);
  }
  if (!statSync(workingDirectory).isDirectory()) {
    throw new Error(`workingDirectory is not a directory: ${workingDirectory}`);
  }
  // ... proceed
}
```

### Layer 2: Business Logic Validation
**Purpose:** Ensure data makes sense for this operation

```typescript
function initializeWorkspace(projectDir: string, sessionId: string) {
  if (!projectDir) {
    throw new Error('projectDir required for workspace initialization');
  }
  // ... proceed
}
```

### Layer 3: Environment Guards
**Purpose:** Prevent dangerous operations in specific contexts

```typescript
async function gitInit(directory: string) {
  // In tests, refuse git init outside temp directories
  if (process.env.NODE_ENV === 'test') {
    const normalized = normalize(resolve(directory));
    const tmpDir = normalize(resolve(tmpdir()));

    if (!normalized.startsWith(tmpDir)) {
      throw new Error(
        `Refusing git init outside temp dir during tests: ${directory}`
      );
    }
  }
  // ... proceed
}
```

### Layer 4: Debug Instrumentation
**Purpose:** Capture context for forensics

```typescript
async function gitInit(directory: string) {
  const stack = new Error().stack;
  logger.debug('About to git init', {
    directory,
    cwd: process.cwd(),
    stack,
  });
  // ... proceed
}
```

## Applying the Pattern

When you find a bug:

1. **Trace the data flow** - Where does bad value originate? Where used?
2. **Map all checkpoints** - List every point data passes through
3. **Add validation at each layer** - Entry, business, environment, debug
4. **Test each layer** - Try to bypass layer 1, verify layer 2 catches it

## Example from Session

Bug: Empty `projectDir` caused `git init` in source code

**Data flow:**
1. Test setup → empty string
2. `Project.create(name, '')`
3. `WorkspaceManager.createWorkspace('')`
4. `git init` runs in `process.cwd()`

**Four layers added:**
- Layer 1: `Project.create()` validates not empty/exists/writable
- Layer 2: `WorkspaceManager` validates projectDir not empty
- Layer 3: `WorktreeManager` refuses git init outside tmpdir in tests
- Layer 4: Stack trace logging before git init

**Result:** All 1847 tests passed, bug impossible to reproduce

## Key Insight

All four layers were necessary. During testing, each layer caught bugs the others missed:
- Different code paths bypassed entry validation
- Mocks bypassed business logic checks
- Edge cases on different platforms needed environment guards
- Debug logging identified structural misuse

**Don't stop at one validation point.** Add checks at every layer.

Overview

This skill enforces defense-in-depth validation across a TypeScript codebase so invalid data cannot trigger deep failures. It provides patterns and utilities to validate at entry points, business logic, environment guards, and debug instrumentation. The goal is to turn intermittent or path-dependent bugs into compile-time or early runtime errors so they become impossible to reproduce in production.

How this skill works

The skill inspects data flows and inserts or recommends validation and guards at four layers: API entry checks, business logic invariants, environment-specific guards, and debug instrumentation. It gives concrete code examples and a process to trace where bad values originate, map checkpoints, and add tests to verify each layer. When a layer is bypassed, other layers still catch the problem and produce actionable diagnostics.

When to use it

  • When invalid input causes failures far from the origin of the data
  • When refactors, mocks, or alternate code paths bypass single-point validation
  • When tests or CI reveal intermittent failures tied to environment or setup
  • When you need robust safeguards around file system, network, or process-modifying operations
  • When failing fast and clear diagnostics would speed debugging and reduce flakiness

Best practices

  • Validate at the API boundary to reject obviously invalid input early
  • Enforce business rules where the operation makes sense, even if inputs passed earlier
  • Add environment guards to block dangerous actions in tests or constrained runtimes
  • Log context and stack traces before risky operations for forensic information
  • Write tests targeting each validation layer to ensure bypass attempts are caught

Example use cases

  • Prevent a git init from running in the wrong directory during tests by adding env guards
  • Throw clear errors when required file paths are missing or not directories at API entry points
  • Add business-level checks to ensure workspace initialization never receives empty projectDir
  • Log stack and context before executing external commands to speed root-cause analysis
  • Audit a data flow across modules and insert validation at every checkpoint to eliminate a recurring bug

FAQ

Won’t duplicate checks slow the code down?

Validation is usually cheap relative to I/O and external commands; prioritize cheap, cheap-early checks and use environment flags to avoid heavy checks in hot paths.

How do I test that layers are independent?

Write tests that intentionally bypass earlier checks (mocks, alternate call sites) and assert later layers still reject invalid states with clear errors.

What if a check is too strict for some contexts?

Scope guards by context (NODE_ENV, feature flags) and document the expectations; keep invariant checks where correctness matters most.