Verify root cause with direct evidence before accepting a fix hypothesis

When diagnosing CI/build issues (e.g., notarization failures), the user drives (and expects the assistant to perform) rigorous, evidence-based root-cause verification rather than accepting a plausible-sounding hypothesis at face value. This includes: inspecting actual dependency source code (not just docs), comparing exact log output/line counts across CI runs, checking package lockfile resolution trees for stale vs updated dependency chains, verifying runner image/OS/tool version changes, and explicitly ruling out alternative explanations (permissions, key type/expiry, format) with concrete evidence before finalizing a diagnosis or proceeding with a fix. The assistant should pause before making changes (e.g., deleting code) to double- and triple-check claims like 'redundant/duplicate behavior,' cross-referencing logs, source code, and CI history rather than relying on assumptions.