Verify by Execution

You MUST execute code to verify -- reading alone is NOT sufficient.

When This Skill Triggers

• After ANY code fix (bug, security, test)
• When reviewing security-critical logic (auth, key blocking, token validation)
• When someone reports "this is broken" -- reproduce FIRST
• When checking test suite health (pass/fail/skip/hang)

Execution Rules

Rule 1: Reproduce Before Fix

Before writing ANY fix, reproduce the reported behavior:

# BAD: Read the code, guess the fix, apply it
# GOOD: Run the failing scenario, see the error, THEN fix

Rule 2: Verify the Fix Works

After applying a fix, run the EXACT scenario that was broken:

# BAD: "I changed line 59, should work now"
# GOOD: Run it, show output, confirm the behavior changed

Rule 3: Security Logic = Execute Both Paths

For any security gate (auth, key blocking, profile check):

• Run with the BLOCKING condition -> verify it blocks
• Run with the ALLOWING condition -> verify it allows
• Run with the EDGE condition (empty, missing, wrong type) -> verify behavior

# Example: Profile-based key blocking
# Test 1: Should block
PROFILE=production node -e "import('./config.js').then(c => console.log('blocked:', c.KEY === ''))"
# Test 2: Should allow
PROFILE=development node -e "import('./config.js').then(c => console.log('blocked:', c.KEY === ''))"

Rule 4: Test Suites = Wait Until Done

Do NOT use tail -1 or timeout to truncate test output.

• Run the FULL suite
• Wait for it to COMPLETE (or hang -- that's a finding)
• Check: pass count, fail count, SKIP count (skip > 0 = investigate)
• Check: did the process EXIT? (hang = bug)

Rule 5: Clean State Testing

When verifying a fix works:

• Consider: does my environment have state that makes it pass?
• Would this pass on a fresh clone?
• Are there installed dependencies that mask the issue?

Rule 6: Cross-Environment Scenarios

For config/env-dependent behavior:

• Test with the env var SET
• Test with the env var UNSET (delete it)
• Test with the env var EMPTY ("")
• Test with the WRONG value

Anti-Patterns (NEVER Do These)

• "I read the code and it looks correct" -> RUN IT
• "The test passes" (but skip count = 12) -> INVESTIGATE SKIPS
• "I fixed it in PR #N" -> RE-VERIFY in current state
• | tail -1 on test output -> WAIT FOR FULL OUTPUT
• "This is a design choice" without running -> RUN IT FIRST, THEN DECIDE

Output Format

After every verification, report:

VERIFIED BY EXECUTION:
- Command: <exact command run>
- Output: <relevant output lines>
- Result: PASS / FAIL / HANG / SKIP(n)
- Environment: <Node version, key env vars>