React/TS Debugging — a log-driven session with the developer

The one idea that matters

You cannot see the running app. The developer can. So treat every bug as a joint investigation where your job is to place instruments (logs) that turn the invisible runtime into evidence, and the developer's job is to run the app, reproduce the bug, and bring the evidence back. The logs they collect ARE the data you reason over — not the source code.

Reading a file and announcing "ah, the bug is on line 42" is a guess. Sometimes the guess is right, but you have no way to know, and when it's wrong you've spent the user's trust and possibly broken working code. A log that fires (or fails to fire) with a specific value is a fact. Build the diagnosis out of facts.

This reframes the whole interaction: you are not a code reader who occasionally asks questions. You are running an experiment, and the developer is your hands and eyes in the lab.