nhouseholder/zero-iteration

Zero Iteration — Get It Right the First Time

Before writing code, run it in your head. Trace the data. Predict the output. Catch the bug before it exists. The fastest debugging is the debugging you never have to do.

Always Active

This skill fires automatically whenever you're about to write or modify code. It's a mental discipline, not a tool — zero token overhead until it catches something.

The Mental Execution Protocol

Before Writing Any Function

1. INPUTS  — What types/shapes come in? What are the edge cases?
2. TRACE   — Step through the logic line by line with concrete values
3. OUTPUT  — What exactly comes out? Does it match the caller's expectation?
4. FAIL    — What makes this break? Null? Empty? Concurrent access? Off-by-one?

Before Modifying Existing Code

1. CURRENT — What does this code do right now? (Read it, don't assume)
2. CALLERS — Who calls this? What do they expect?
3. CHANGE  — Apply your modification mentally
4. TRACE   — Run through with the same inputs as before — does it still work?
5. EDGE    — Run through with edge case inputs — does the change break them?

Common Pre-Bugs to Catch

Data Shape Mismatches

API returns: { data: { items: [...] } }
Code assumes: response.items  ← WRONG: response.data.items

Rule: Verify the actual shape before accessing nested properties.

Off-by-One Errors

for (let i = 0; i <= arr.length; i++)  ← WRONG: should be <
arr.slice(0, n)  ← Does this include index n? No, it's exclusive.

Rule: Trace with arrays of length 0, 1, and 3. Check boundaries.

Async Timing

const data = fetchData()  ← Missing await
setState(newVal); console.log(state)  ← State hasn't updated yet

Rule: For every async call, verify await/then. For every state update, don't read the new value immediately.

Type Coercion Traps

"5" + 3 = "53"  (string concat, not addition)
null == undefined  (true)
[] == false  (true, but [] is truthy)

Rule: When mixing types, trace the actual coercion.

Reference vs Value

const copy = original  ← Same reference, not a copy
arr.sort()  ← Mutates in place, doesn't return new array (well, it does, but it's the same array)

Rule: When "copying" objects/arrays, verify it's a real copy if mutation matters.

Environment Variable / Config Traps

UFC_NUM_EVENTS=0 → num_events = int(os.environ.get("UFC_NUM_EVENTS", 71))
  → num_events = 0
  → if len(events) >= 0: break  ← Loop exits IMMEDIATELY

Rule: When setting env vars or config values, trace them through ALL downstream logic. Zero, empty string, and negative values are the most dangerous. 0 is especially treacherous — it's falsy AND satisfies >= 0.

Import/Export Mismatches

export default function X()  →  import { X }  ← WRONG: import X
export function X()  →  import X  ← WRONG: import { X }

Rule: Before writing an import, check the export style.

Arithmetic Spot-Check

When writing code that produces numbers (P/L, units, stats, percentages, scores):

1. Pick ONE concrete example — a specific bet, game, row, or data point
2. Calculate the expected output by hand — what should this cell/field show?
3. Trace through your code with that example — does it produce the same number?
4. If the numbers don't match → your formula is wrong. Fix BEFORE writing.

Common math bugs this catches:

• Loss not tracked (wins show +units but losses show nothing instead of -1)
• Totals that don't sum correctly (missing a category from the total)
• Wrong sign (showing -2.5 instead of +2.5 for a win)
• Integer division when you need float (Python 2 style bug)
• Off-by-one in count-based stats

The Three-Value Test

For any function you write, mentally run it with three inputs:

1. The happy path — Normal expected input
2. The empty/zero case — Empty string, empty array, 0, null
3. The boundary case — Max length, negative number, special characters

If all three produce correct output → write the code. If any fails → fix the logic BEFORE writing.

Cross-Check Against Known Reasoning Failures

Before writing code, mentally scan anti-patterns.md lessons (loaded at session start via total-recall). Ask: "Am I about to make a mistake I've made before?"

Common reasoning failure categories to check:

• Data freshness — Am I assuming this data is current without verifying?
• Sort/order assumption — Am I assuming a list is ordered a certain way without checking?
• Scope assumption — Am I assuming this change only affects one place?
• Trusting without verifying — Am I trusting algorithm/API output without a sanity check?

If the current task matches a known reasoning failure category → apply the lesson BEFORE writing code, not after finding the bug.

Anti-Rationalization Check

Before claiming a task is complete, run this check:

1. "Did I actually verify, or am I rationalizing?" — If you changed 3 functions but only traced 1, you didn't verify — you rationalized that the others are "obvious."
2. "Am I claiming completion because it SHOULD work, or because I CHECKED it works?" — "Should work" is not evidence. Trace it or test it.
3. "Would I bet money on this?" — If the answer is "probably" instead of "yes", you're not done.

Red flags that you're rationalizing:

• "This is straightforward so it doesn't need verification" — the straightforward ones are where bugs hide
• "I already checked something similar" — similar ≠ same
• "The change is small so it can't break anything" — small changes cause big failures
• "It worked before so it still works" — you just changed the code, "before" is irrelevant

When you catch yourself rationalizing: stop, go back, actually verify.

Rules

1. Trace before you type — Never write a function without mentally running it first
2. Concrete values — Don't trace with "some object", trace with { id: 1, name: "test" }
3. Check the callers — Your function is only correct if it satisfies its consumers
4. Three-value test — Happy path, empty case, boundary case. Every time.
5. Silent when clean — Don't announce "I traced through the code mentally." Just write correct code.
6. Trace env vars end-to-end — Before setting ANY env var or config value, trace it through all code paths that read it. Zero and empty string are the most common traps.
7. Speak up when caught — If you catch a pre-bug, briefly mention it: "Caught an off-by-one before writing — using < not <="
8. Cross-check past failures — Before writing, scan known reasoning failures. Don't repeat mistakes that are already documented.