How we verify
Useful without pretending certainty.
We treat an error page as a small evidence review: exact string, environment, likely cause, safest steps, expected result, and the limits of what the sources prove.
1. Exact error before broad advice
Each fix page starts with one or more search-visible error strings. A generic code such as -32000 is not enough on its own; the surrounding product, plugin, and log signature must match.
2. Primary and first-hand sources
We prefer official documentation, source code, specifications, and upstream issue reports containing a reproducible environment. Community reports can establish that someone experienced or worked around a problem, but they do not become vendor guarantees.
3. Status labels
- Confirmed workaround: a first-hand report says the step restored operation in the stated environment.
- Partial workaround: the result is temporary, version-specific, or contradicted by another reproduction.
- Open issue: there is enough evidence to diagnose safely, but no credible fix yet.
4. Closed is not fixed
An issue closed as stale, duplicate, invalid, or not planned is not described as a shipped fix. We state the closure context when it changes how readers should interpret the evidence.
5. Safety and reversibility
We order reversible diagnostics before reinstalls or version changes, recommend backups before configuration edits, and avoid telling readers to weaken security boundaries merely to silence an error.
6. Updates and corrections
Pages show a checked date and version notes. When a source documents a shipped resolution or current code changes the diagnosis, the page should be revised rather than silently preserving an old workaround.
Found a material error? Use the linked upstream evidence to verify it, then revisit the relevant AgentFix page; a public correction channel will be added before any reader-submission workflow is activated.