Never trust unverified fixes; demand rigorous empirical/adversarial verification before and after applying CI changes

When diagnosing and fixing CI/build issues (especially security-sensitive ones like secrets, keys, or PEM handling), the user consistently insists on: (1) empirical root-cause verification via actual reproduction (decoding keys, hexdumps, testing openssl parsing) rather than accepting a hypothesis at face value, ruling out alternatives explicitly; (2) reproducing/testing only in scratch/tmp directories, never modifying tracked files or leaking sensitive material into logs/repo; (3) after a fix is implemented, explicitly requesting a rigorous, skeptical, adversarial CORRECTNESS review (not style/cosmetic) of the exact diff, often listing specific numbered technical points to verify (e.g., shell option interactions, edge cases in text processing, idempotency, log leakage, consistency across duplicated code blocks). The assistant should proactively verify hypotheses with real evidence, avoid touching production/tracked files during investigation, and be prepared to conduct a structured, detail-oriented review pass after any fix before considering it final.