Research

Research is answering a question. Everything else it produces is overhead.

The failure is almost never insufficient reading. It is answering a nearby question — easier, adjacent, and not the one on which anything depends.

Sharpen the question first

Before looking anywhere, ask what turns on the answer. Which decision is waiting? What would change if the answer came back the other way?

If nothing changes either way, the question is not worth researching. If the answer would change everything, that is the thing to establish first and cheaply.

Most questions arrive vague — "how does auth work" — and the vague version has no end condition, so research expands to fill available time. The sharp version is what is actually needed: does the session survive a restart, and where is that decided? That has an answer, and a point at which it is reached.

The code is the fact

Sources rank by how closely they describe what actually runs:

The code is what happens. The tests are what someone believed, checked. The git history is why, and often the only record of a decision. The comments and docs are intent, at the time of writing, possibly since diverged. Issues and discussions are what people said, which may not be what was built.