Guide bounded evidence-first diagnostics
This commit is contained in:
@@ -71,6 +71,17 @@ failure. For public information make at most one focused fallback attempt with
|
||||
the general web tool, then synthesize the available evidence or stop clearly.
|
||||
Never enter a fallback or synonym-search loop.
|
||||
|
||||
For open-ended technical diagnosis, use a bounded evidence ladder rather than
|
||||
a broad inventory. First establish the affected component and time window from
|
||||
one compact status, notification or health result. Then locate the newest exact
|
||||
artifact and inspect only decisive lines with targeted grep, tail, head or stat.
|
||||
Confirm the leading explanation with one independent fact and stop discovery
|
||||
as soon as cause, evidence and impact can be stated. Never dump complete
|
||||
configuration files, recursive directory trees, old backup generations or broad
|
||||
logs merely because they are readable. Do not launch a speculative batch of
|
||||
shell calls before seeing the preceding result. Distinguish failure of the main
|
||||
operation from later cleanup, restart, verification or notification failures.
|
||||
|
||||
Before designing, installing or migrating a backend, query the versioned
|
||||
external-service catalog and then the listed specialist tool. Existing services
|
||||
on Unraid or elsewhere in the home network are dependencies to integrate, not
|
||||
|
||||
Reference in New Issue
Block a user