gobby-hooks public releases are out of sync: crates.io 0.2.1 has block-reason fix, GitHub releases stop at 0.1.1

[joshwilhelmi]

Task context: Gobby task #12130 (block observability + upstream ghook reason forwarding).

We investigated the public ghook / gobby-hooks distribution chain because users still sometimes report the bare fallback string Blocked by hook, and the public code/release story is currently inconsistent.

Findings

• crates.io package is gobby-hooks, not ghook.
• crates.io points gobby-hooks to this repo, and crates/ghook/Cargo.toml publishes package gobby-hooks.
• gobby-hooks 0.2.0 on crates.io only extracts top-level stopReason, user_message, and reason in extract_reason().
• gobby-hooks 0.2.1 on crates.io adds nested hookSpecificOutput.permissionDecisionReason / hookSpecificOutput.reason lookup, which is the fix task #12130 expected for Claude-style block responses.
• GitHub releases/tags for gobby-hooks-v* currently stop at gobby-hooks-v0.1.1. I could not find public GitHub release/tag assets for gobby-hooks-v0.2.0 or gobby-hooks-v0.2.1.
• Installer in src/gobby/cli/install_setup.py resolves latest version from crates.io, then tries GitHub release assets first via gobby-hooks-v{version}, then falls back to cargo-binstall / cargo install.

Repro

1. Check https://crates.io/api/v1/crates/gobby-hooks and note that latest public crate version is 0.2.1.
2. Check https://api.github.com/repos/GobbyAI/gobby-cli/releases?per_page=100 and filter for gobby-hooks-v*. Public GitHub releases currently stop at gobby-hooks-v0.1.1.
3. Compare released crate sources:
   • 0.2.0: extract_reason() only checks top-level keys, so a Claude response shaped like {"hookSpecificOutput":{"permissionDecision":"deny","permissionDecisionReason":"Task #12130 needs visible block reasons"}} still collapses to Blocked by hook.
   • 0.2.1: nested hookSpecificOutput.permissionDecisionReason lookup is present.
4. Result: when a user reports bare Blocked by hook, it is hard to tell whether they are on an old GitHub asset, a 0.2.0 crate install, or some unreleased/local build, because public releases and public crate versions are not aligned.

Expected

• One public version story for gobby-hooks.
• GitHub release assets exist for every published gobby-hooks crate version, or GitHub release install path is removed/deprioritized.
• ghook --version / --diagnose expose enough provenance to identify install method/build source during bug reports.

Recommended fix

• Publish matching gobby-hooks-v0.2.0 and gobby-hooks-v0.2.1 GitHub releases, or stop preferring GitHub release download in installer until release parity exists.
• Add a CI guard that fails a gobby-hooks publish if crates.io version, Git tag, and GitHub release assets diverge.
• Extend ghook --version or --diagnose with build provenance (crate version, tag/commit, install method if known).
• Keep regression coverage for nested hookSpecificOutput.permissionDecisionReason, since task #12130 depends on that path for observable block reasons.