docs: document the client-restart stage of the release delivery chain (README / Home / mcp-server README / requirements specs)

[liplus-lin-lay]

目的

リリースの配送鎖が npm publish で終わっていると誤認しやすい。実際にはその先に 利用側プロセスの再起動 という段があり、これがどこにも書かれていなかった。v0.11.9 のリリース直後に実測で踏んだ事象（#247）をドキュメントに固定する。

変更内容

利用者向けの導線（再起動の事実 + 確認手段）

• README.md — ## Updating
• docs/Home.md — ## 更新（wiki 日本語トップページ、README のミラー）
• mcp-server/README.md — ## Updating（npm パッケージ README、npx 利用者が読む面）

いずれも次の 2 点を書いた:

1. npx がバージョンを解決するのは プロセス起動時の一度きり（クライアント設定で @latest を指定していても同じ）。稼働中のクライアントは起動時のバージョンを保持し続けるので、新版を反映するには MCP クライアント（Claude Desktop / Claude Code / Codex）の再起動が要る。
2. registry の確認には npm view github-webhook-mcp version --prefer-online を使う。npm CLI が registry メタデータをキャッシュするため、--prefer-online 無しでは publish 直後に旧版を返しうる。

mcp-server/README.md には、この面が特に効くのは プロキシの静的ツールスキーマを変えたリリースである旨も添えた（スキーマはプロキシ自身のコード内 TOOLS 定数から返るため、プロセスが替わるまで旧定義が見え続ける）。

リリース手順側（配送鎖と完了条件）

• docs/0-requirements.md / docs/0-requirements.ja.md — ## CI/CD 配下に ### 配送鎖と完了条件 を追加

merge → gh release create → CD (npm-publish) → registry の latest 更新
      → 利用側 MCP クライアントの再起動 → npx が新版を解決 → 利用側に到達

後半 2 段が CD の外側にあること、したがって 「registry が新版を返す」はリリース完了の判定基準にならないことを明記した。実測値（registry が 0.11.9 を返している間、稼働中のクライアントは 0.11.8 のまま。0.11.9 に移ったのは Claude Desktop を再起動した時点）を根拠として本文に残している。

付随修正

docs/0-requirements.ja.md の CD トリガー表とリリースフローが、廃止済みの v* タグ push 起動のまま残っていた。追加した節のすぐ上で同じファイルが自己矛盾する状態になるため、cd.yml の実体（release: types: [published] / ジョブは build-mcpb・attach-mcpb・npm-publish）に合わせた。docs/0-requirements.md 側は既に正しく、変更していない。

制約の遵守

issue の制約どおり、npx のキャッシュ解決挙動そのものは本リポジトリの管理外として規定していない。書いたのは「再起動が要る」という事実と確認手段までで、その旨も仕様本文に明記した。

受け入れ条件の充足

• 配送鎖の最終段（利用側再起動）がドキュメントに書かれている — 上記 5 ファイル
• リリース完了の判定基準が「registry 更新」で止まらないことが読み取れる — 両要件仕様の ### 配送鎖と完了条件

自己レビューによる訂正（2e1d05b）

初版は 4 面すべてで「再起動すると npx が新版を新規のキャッシュディレクトリに取得し、旧ディレクトリは旧版のまま選択されなくなる」と書いていた。これは誤りで、#247 本文の記述をそのまま引き継いだもの。同一マシンの再起動前後の実測では 3 つのディレクトリが両状態に同じく存在し、新規作成は起きていない。実際に動いていた 1 本（70bf1377065b9d0a）が in place で更新され、その mtime が再起動時刻に一致する。残る 2 本は 7 月中旬以来触られていない残骸で、そもそも live ではなかった。「旧ディレクトリが選択されなくなる」という選択イベントは発生していない。

訂正はキャッシュ機構の記述を全面削除とし、正しい機構の説明への差し替えはしていない。理由は 2 つ:

1. 本節が自ら「npx のキャッシュ解決挙動そのものは本リポジトリの管理外」と宣言しており、機構を記述すること自体がその境界と矛盾する。
2. 読み手にとって load-bearing ではない。必要なのは「新版を反映するには再起動」と「registry の確認は --prefer-online」の 2 点であり、npx がパッケージをどう格納するかはどちらの指示も変えない。

配送レベルで観測された事実（registry が 0.11.9 を返す間もクライアントは 0.11.8、移行したのは再起動時点）は残した。npm CLI の registry メタデータキャッシュ（--prefer-online を付ける理由）は別軸の実測であり、これも維持している。

検証

ドキュメントのみの変更でコードは触っていない。CI（node --check / mcp-server テスト / worker typecheck + dry-run deploy + テスト）への影響なし。事実関係は一次情報で確認した:

• .github/workflows/cd.yml — トリガーとジョブ名（.ja.md の付随修正の根拠）
• mcp-server/server/index.js — TOOLS 定数を ListToolsRequestSchema ハンドラがそのまま返す静的スキーマであること（README の記述の根拠）
• 実測値は docs: release does not reach a running client until the local npx process restarts #247 本文および訂正コメント（再起動後の実測）から採った

Closes #247

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	github-webhook-mcp	2e1d05b	Aug 03 2026, 01:44 AM

[liplus-lin-lay]

AI self-review (auto mode)

判定: pass。merge する。

検証は差分の実読で行った。CI は head SHA 2e1d05b に対して 3 本すべて green、mergeable state は CLEAN。docs のみ 5 ファイル +104/-6。

受け入れ条件

• 配送鎖の最終段（利用側再起動）がドキュメントに書かれている — 利用者向け 3 面（README.md / mcp-server/README.md / docs/Home.md）に Updating / 更新 節、リリース手順側に 配送鎖と完了条件 節。
• リリース完了の判定基準が registry 更新で止まらないことが読み取れる — 「registry が新版を返す はリリース完了の判定基準にならない」を太字で明示。プロキシの静的ツールスキーマ変更時に特に効くことも併記。

self-review で差し戻した点（修正済み）

初版は全 4 面に「再起動すると npx が新規のキャッシュディレクトリに新版を取得し、旧ディレクトリは旧版のまま残る」と記していた。これは事実に反する。同一マシンで再起動前後を実測した結果:

再起動前              再起動後
0.11.8  3f9cf0a6…     0.11.8  3f9cf0a6…
0.11.8  70bf1377…     0.11.9  70bf1377…   ← その場で更新
0.11.8  7eee0676…     0.11.8  7eee0676…

ディレクトリ集合は前後で同一であり、新規作成は起きていない。1 本が中身を入れ替えただけで、mtime も再起動時刻と一致する。残り 2 本は 7 月のまま手つかず。

この誤りの発生源は #247 の私の訂正コメントであり、担当はそれを忠実に運んだ。 供給源を断つため #247 の本文とコメントも訂正済み。

修正方針は「正しい機構説明に書き直す」ではなく 機構説明の全面削除 とした。理由 2 点:

1. 本 issue 自身が「npx のキャッシュ解決挙動は本リポジトリの管理外」を制約に置いており、機構を語ること自体がその境界と矛盾する
2. 読者に荷重を持つのは「再起動が要る」と「--prefer-online で確認する」の 2 点のみで、内部機構は持たない

削除後、5 ファイルを grep して機構記述の残存が無いことを確認した（0 hits）。残る cache 言及は npm CLI の registry メタデータキャッシュのみで、これは --prefer-online を根拠づける別途実測済みの事実。

担当の判断 2 件（いずれも採用）

• installation.md / installation.ja.md に追記しなかった。 issue が名指したのは README 2 面とリリース手順 docs。5 面目・6 面目はカバレッジではなく重複になる。docs/Home.md のみ名指し外だが README.md の日本語ミラーであり、追記しなければ乖離するため妥当。
• 0-requirements.ja.md の退役済み CD トリガ記述を是正した（scope 外の追加）。 新節が v* タグ push 記述の直下に入るため、放置すると同一ファイルが 10 行以内で自己矛盾する。cd.yml を私も独立に読み、release: types: [published] とジョブ 3 本（build-mcpb / attach-mcpb / npm-publish）を確認した。

記録

担当が PR 本文側の同一記述も自発的に訂正し、自己レビューによる訂正 節として測定値と削除選択の理由を残している。merge が保存する記録から欠陥を除く措置として妥当。