Data Trace
Data trace debugging pattern — Source → Transform → Result, never guess-fix
Tags
Overview
Purpose
Data trace debugging pattern — Source → Transform → Result, never guess-fix
Rules
DTR-001: Follow Data Source → Transform → Result pattern. Find where data originates, trace each transformation, verify output.
Systematic tracing eliminates guesswork. Most bugs are at transformation boundaries, not at source or result.
Verification: Debug log: shows data at source, each transform step, and final result.
DTR-002: Always identify the data source before investigating transforms. Log actual values at origin.
If the source is wrong, no amount of transform debugging will help. Source-first saves time.
Verification: Debug session: source value logged and verified before any transform investigation.
DTR-003: Strategic logging only: log at source, at each transform, at result. No random console.logs.
Random logging creates noise that obscures the signal. Strategic logging at boundaries gives clear before/after at each step.
Verification: Code review: log statements at data boundaries, not scattered throughout functions.
DTR-004: When debugging transforms, log input AND output to verify correctness.
Logging only output leaves input as an assumption. Logging both proves whether the transform itself is correct.
Verification: Transform functions: input and output both logged during debug sessions.
DTR-005: For UI bugs, verify Route → State → Component data flow. URL determines state, state determines render.
UI bugs are often state bugs. The URL→state→render chain is deterministic — verifying each link isolates the fault.
Verification: UI debug: route params verified, derived state verified, component props verified.
DTR-006: Bug symptoms often appear far from cause. Trace data upstream — first mismatch reveals the bug.
Fixing symptoms creates patches that mask root causes. Upstream tracing finds the actual source of incorrect data.
Verification: Bug fix: root cause identified via upstream trace, not by patching symptoms.
DTR-007: NEVER change code before understanding data flow. Understand the problem first, then fix.
Premature fixes often fix the wrong thing or introduce new bugs. Understanding first ensures the fix is correct.
Verification: Debug session: data flow documented before any code changes.
DTR-008: When data flow seems correct but behavior is wrong, verify pattern matching order and fallback logic.
Pattern matching bugs are invisible when individual patterns work. The bug is in ordering or fallback, not individual cases.
Verification: Edge case: pattern match order tested with boundary inputs.