wharfy 0.4–0.5 — 既定でエージェントが wharfy を使い、install.sh はどこにでも置け、PR は重複しない

0.3.0 以降に塞いだ3つの穴（0.4.0–0.5.0）。それぞれ「問題点 → 変更前 → 変更後」で。

エージェントが wharfy を使わずリリースを再発明した

• 問題点: 初回リリース以降、「リリースして」と頼まれた AI エージェントは、wharfy を使わず手順を自前で組み直しがち。
• 変更前: リリースが wharfy 経由であることを、リポジトリの何もエージェントに伝えていなかった。
• 変更後: wharfy init が AGENTS.md / CLAUDE.md に小さな管理ブロックを書き、推測せず wharfy agent（常に最新の地図）を実行するよう誘導。冪等で、未設定なら status と release / publish 成功時にも促します。

install.sh が GitHub Releases に固定だった

• 問題点: script.base_url はスキーマにあるのに配線されていない dead field で、install.sh を自前ドメインから配信できなかった。
• 変更前: 案内する curl | sh の URL は常に GitHub Release のアセットを指していた。
• 変更後: script: { base_url: … } を指定すると、案内文も status の probe もその自前ドメイン / CDN を追従。（おまけ: install.sh の実行時メッセージが “wharfy” ではなく利用者のアプリ名を名乗るように。）

gated チャネルが重複 PR を出した

• 問題点: winget / homebrew-core は --yes のたびに新しい PR を出し、前回の審査が未完了でも構わず提出していた。
• 変更前: 審査中の PR があるのに新バージョンを publish すると、2 本目の PR が開いてレビュアーの負担に。
• 変更後: wharfy が記録済み PR の現状をまず確認。open なら提出せず案内し、merge / close 済みなら新バージョンを提出。

入れ方

brew upgrade wharfy / scoop update wharfy / go install github.com/ShiroDoromoto/wharfy/cmd/wharfy@latest。Linux は apt / yum リポジトリから。