hardware-triage
Hardware triage
Reduce uncertainty about a hardware-related failure with the smallest safe experiment that can distinguish likely causes.
Establish the failure
Read the supplied logs, code, configuration, and hardware notes. Capture expected versus observed behavior, a minimal reproduction, device and board revision, power source, connected peripherals, firmware/OS/runtime/model versions, and the last known good state. Separate observed facts from the user's interpretation. Ask only for missing facts that affect the next decision.
Preserve logs and configuration before changes. Locate the failure relative to power-up, enumeration, data capture, inference, communication, and actuation; investigate the layers implicated by evidence rather than requiring a universal checklist.
Rank hypotheses
Use timing, error messages, recent changes, and known-good comparisons to propose a short ranked list. For each hypothesis give supporting evidence, conflicting evidence, and a check that would distinguish it from alternatives. Use qualitative confidence tied to evidence rather than invented probabilities.
A correlation is a lead, not a diagnosis. For example, a device disconnect during motor startup could implicate power or interference, but logs alone may not distinguish them. An inference failure can also originate upstream in capture or preprocessing. Prefer read-only inspection and existing logs before interventions.
For pin assignments, voltage compatibility, firmware behavior, or device-specific procedures, consult authoritative documentation for the exact model and revision. If the mapping is unresolved, request the identifier or document; do not invent a pinout or substitute a similar board's electrical limits.