doubt-driven-developmentlisted

# Doubt-Driven Development A confident answer is not a correct one. Long sessions accumulate context that quietly turns assumptions into "facts" without anyone noticing. Doubt-driven development materializes a fresh-context reviewer, biased to **disprove** not approve, before any non-trivial output stands. This is not `/review`. `/review` is a verdict on a finished artifact. This is an in-flight posture: non-trivial decisions get cross-examined while course-correction is still cheap. ## When to Use A decision is **non-trivial** when at least one of these is true: - It introduces or modifies branching logic - It crosses a module or service boundary - It asserts a property the type system cannot verify (thread safety, idempotence, ordering, invariants) - Its correctness depends on context the future reader cannot see - Its blast radius is irreversible (production deploy, data migration, public API change) **When NOT to use:** - Mechanical operations (renaming, formatting, file moves) - Following a clear, unambiguous instruction - Reading or summarizing existing code - One-line changes with obvious correctness - The user has explicitly asked for speed over verification If you doubt every keystroke, you ship nothing. ## The Process ### Step 1: CLAIM - Surface what stands Name the decision in two or three lines: ``` CLAIM: "The new caching layer is thread-safe under the read-heavy workload described in the spec." WHY THIS MATTERS: a race here corrupts user data