happier-diagnose

# Happier Diagnose Investigate a Happier runtime/support incident from primary evidence, determine the originating cause when the evidence supports it, and report what is known, what is derived, and what remains unverified. Diagnosis is read-only: do not edit repository source or silently turn the investigation into a fix. For a GitHub issue or coherent issue bundle, use `skills/happier-issue-diagnose`; it owns untrusted issue intake, private maintainer-evidence capability checks, version/release disposition, and the GitHub-facing report while composing this runtime evidence method when applicable. For a raw multi-issue corpus, use `skills/happier-issue-triage` first. If the user requests a repository correction, finish the diagnosis or establish the deciding evidence, then use `skills/happier-implement` and its bug-fix loop. User-side recovery actions, private diagnostics upload, and public issue creation remain separate actions with their own authority. ## 1. Establish the observed incident Inspect evidence already supplied or locally available before asking the user for more. Capture: - observed behavior and failure window; - expected behavior when it is established; - affected session, daemon, provider, server, account, host, and platform; - version/build/runtime identity; - what still works and the practical impact; - whether the user wants diagnosis only, local recovery guidance, or later reporting. If no usable description or evidence exists, ask one concise que...