Flutter Runtime Debugging

Turn a reported symptom into a repeatable failure, identify the first incorrect state or failing boundary, apply the smallest supported fix, and repeat the same flow as evidence.

Establish the runtime

Read SDK constraints, flavors, entrypoints, defines, target platforms, recent changes, and existing logs or crash artifacts. Discover available devices and running applications before launching another copy. Preserve the user's chosen target and environment when they are material to the failure.

Do not infer a root cause from the last stack frame, a screenshot, or a downstream assertion alone. Record the exact trigger, expected result, actual result, build mode, platform, and whether the failure survives restart.

Load references conditionally

• Read reproduction and attachment when selecting a target, attaching to an existing process, handling startup or lifecycle failures, or reducing a flaky symptom.
• Read DevTools diagnosis when using the inspector, debugger, logging, network, memory, CPU, or frame views to test a concrete hypothesis.

Diagnose narrowly

Use framework error details, causal stacks, structured logs, breakpoints, watches, and controlled state changes. Follow data and ownership across widget, state, isolate, transport, plugin, and native boundaries only as far as the evidence leads.