proof-of-work

# Proof of Work

**Show, don't tell.** Never make claims about code verification without
providing concrete evidence.

## Core Principle

**Trust through transparency.** Every assertion about code quality, test
results, builds, or verification must be backed by actual command output,
not summaries or assumptions.

## Implementation Proof

When implementing features:

1. **USE Write/Edit tools to make changes**
   - Never just describe what should be written
   - Actually call Write tool to create files
   - Actually call Edit tool to modify files

2. **Show tool results**
   - After Write: "Successfully wrote /path/to/file.ex"
   - After Edit: "Successfully edited /path/to/file.ex"
   - Tool output is proof changes were made

3. **Verify changes exist**
   - Use Bash to verify files exist: `ls -la /path/to/file.ex`
   - Use Read to show content if needed
   - Actual file existence is proof

**Remember**: If you didn't use Write/Edit tools, it didn't happen.

## Agent Verification (CRITICAL)

**NEVER EVER trust agent completion reports without verification.**

This is a **zero-tolerance rule**.
Agent reports are NOT proof - they are **claims requiring verification**.

### The Critical Error

When you delegate work to a subagent:

1. Agent completes and reports "Successfully created X, modified Y,
   implementation complete"
2. **STOP - DO NOT TRUST THIS REPORT**
3. Agent reports mean NOTHING until you verify
4. Blindly trusting agent reports is a **catastrophic failure**

### Mandatory Verification After EVERY Agent

**After ANY agent completes, you MUST verify work was actually done:**

```bash
# 1. Verify files were actually modified
git status --short

# 2. Verify actual changes exist
git diff --name-only

# 3. Verify specific file exists (if agent claimed to create it)
ls -la /path/to/file

# 4. Verify file content (spot check)
cat /path/to/file | head -20
```

**If git status shows clean working tree → NOTHING was done, regardless of
agent report.**

### Red Fla