home / skills / microck / ordinary-claude-skills / defense-in-depth

defense-in-depth skill

/skills_all/defense-in-depth

This skill enforces defense-in-depth validation to catch invalid data at every layer, making bugs structurally impossible.

npx playbooks add skill microck/ordinary-claude-skills --skill defense-in-depth

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

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

# 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: add checks at every layer data passes through so invalid input cannot reach dangerous operations. It helps turn intermittent bugs caused by unexpected values into structurally impossible failures by combining entry validation, business logic checks, environment guards, and debug instrumentation.

How this skill works

The skill inspects data flows and inserts validation at four layers: API/entry boundaries, business logic, environment-specific guards, and debug instrumentation. It provides patterns and example checks so each layer rejects or contains invalid values before they reach deep execution paths like file operations or external commands.

When to use it

  • When an invalid value causes failures deep in execution (e.g., unexpected empty strings or missing paths).
  • When a single validation location has been bypassed by other code paths, tests, or mocks.
  • When operations have environmental risk (tests manipulating git, file system, network calls).
  • When you need stronger forensic context to diagnose rare failures.
  • During refactors that change call paths or when adding public APIs.

Best practices

  • Validate at the API/entry boundary to reject obviously invalid input early.
  • Repeat meaningful sanity checks in business logic to guard against alternate call paths or mocks.
  • Add environment guards to prevent dangerous operations in tests, CI, or production-specific contexts.
  • Log context (arguments, cwd, stack) in debug mode before executing risky operations for fast forensics.
  • Test each layer by attempting to bypass earlier checks to confirm later layers catch invalid data.

Example use cases

  • Reject empty or non-existent working directories at API boundary to avoid accidental operations in project root.
  • Refuse git init in tests when the target directory is outside a temp directory to prevent repository pollution.
  • Add required-argument checks inside workspace initialization to catch empty values injected by mocks.
  • Log argument values and stack traces before running external commands to speed root-cause analysis of rare failures.
  • Map the data flow for a failing test, then add validation at every checkpoint to make the bug unreproducible.

FAQ

How many layers of validation are enough?

Use at least the four layers: entry, business logic, environment guards, and debug instrumentation; add more where domain rules require it.

Will this slow systems down?

Simple sanity checks and conditional debug logging have negligible cost; keep heavy checks optional or gated by debug/testing flags.

Can tests still bypass checks?

Tests can bypass a given layer, which is why multiple layers are required: later guards and environment checks catch bypasses and make the bug impossible to reproduce.