systematic-debugging

First state the symptom precisely, then form two or three falsifiable hypotheses such as a wrong parent extension ID, a malformed event signature, or a client cache issue. Verify each with read-only queries before changing anything, then fix only the confirmed root cause and re-verify.

It is a five-step process: list verifiable symptoms, write down two to three falsifiable hypotheses, gather evidence one hypothesis at a time using read-only tools, lock a single root cause, and then apply a targeted fix followed by verification.

Empty results usually come from a wrong object identifier, a mismatched extension ID, or a rolled-back transaction. Check the exact identifiers you passed against list queries and confirm the record exists with a direct read before assuming the tool is broken.

Stop immediately when a tool returns an error, results contradict expectations, or the same operation behaves inconsistently twice. Retrying without a formed hypothesis is an anti-pattern; switch to evidence gathering with read-only tools first.

Return to refining the symptom description or generating new hypotheses rather than guessing. If still stuck, honestly report which hypotheses were excluded and suggest concrete external checks such as client or server logs.