Investigate

Determine unambiguously what the report means from the system's perspective. Collect the available evidence for it, such as error output, logs, and failing inputs, and check what changed recently in the affected area. Then establish whether it is real with a precise reproduction. If not, pause and report that result.

Start at the observed effect and identify the code paths directly responsible. Climb one layer at a time across call frames, processes, network hops, and persistence boundaries. Go only as wide and deep as the evidence requires.

Keep an explicit hypothesis at every branch and try to disprove it. Prefer the simplest explanation that accounts for all observed evidence. Do not jump to solutions before diagnosis.

Before proposing a change, name the fundamental constraints, including the relevant data flows and the entry points that reach the affected code paths.

Standards

• Resolve every cited call frame and reference.
• Distinguish observations, inferences, and unknowns.
• Map relevant dependencies and identify other reports or users affected by the same mechanism.
• Question assumptions about timing, state, identity, retries, and execution boundaries.
• Stop when required evidence is unavailable rather than filling gaps with guesses.

Questions for every hypothesis

• How can this be disproved?
• Is there a simpler or more likely explanation?
• Which source references remain unresolved?
• Do the surrounding code and runtime state support the conclusion?
• Does this explain both why the behavior occurs and why it began now?

Return compact but complete evidence, the diagnosed mechanism, a decision tree when useful, and the smallest prognosis justified by the evidence.