痛みの分解：ページが開くこととゲートウェイ健全性は別物
痛み1：版ズレ。グローバル npm と pnpm や古い tarball を併存させるとシェルの openclaw と監督が起動する gateway が食い違う。両 --version と which、plist／unit の実行行を同一チケットに貼り、4.x 文 のスナップショット習慣に揃える。
痛み2：ペアリング状態とデバイス ID。アップグレード後の強化で既存デバイス信頼が失効し pairing required がループすることがある。承認者が曖昧だとランダムに見える再接続競合が起きる。誰が承認できるか、どのブラウザプロファイルが運用正とするかを文書化し、workspaceAccess 最小権限 変更と同じ変更票で扱う。
痛み3：逆プロキシの途中設定。allowedOrigins 欠落、WebSocket 昇格ヘッダ不足、TLS 中間証明書の古さ、localhost と公開 DNS のコールバック混線は 401／403／502 をアプリ不具合に見せる。Nginx／Caddy 本番ガイド を先に踏んでから gateway を再インストールする。
痛み4：ウォームリロードだけで済ませる。一部 JSON はホットリロードでも、ペアリングやプラグイン登録はコールド再起動が要る。手順は daemon インストール記事 の再起動節と同期させる。
痛み5：ワークスペース境界を切断表示に混同。workspaceAccess やシェルツール制限は汎用バナーに潰れがち。まず openclaw doctor を自動修正なしで読み、最小権限マトリクス と突き合わせる。
痛み6：ノート単独。スリープや VPN、拡張機能で WebSocket が不安定。常時オン リモート Mac へ移し、OIDC マトリクス の Runner と同一性で合成 RPC を打つ。
補足：チケットには CLI／gateway semver、doctor 要約（マスク可）、最終成功チャネル時刻、公開 notAfter、本番 DNS での RPC p95、loopback のみかを毎時追記する。ブリッジ期は CLI・監督・逆プロキシの三本同時変更を避け、層別手順 を再演する。
三層と測定可能フィールド：チケットを再現可能に
ゲートウェイ運用と doctor の層別手順 に従い、ローカルプロセスとポート、gateway スコープ RPC、外部 API とアダプタの順で切り分ける。層を飛ばすとヘッダ誤設定でもバイナリを入れ替える誤対応になる。
4.x doctor の非推奨警告はリリースノート TODO として残し、高負荷時の単発障害にしない。外向きコミュニケーションは失敗層・証拠・次段階 ETA を明示し不要な再インストール圧力を下げる。
意思決定マトリクス：版ズレ、ペアリング期限切れ、逆プロキシ、権限、リモート移行
| 症状群 | 優先アクション | 効果 | リスク |
|---|---|---|---|
| semver 不一致 | チャネル統一、スナップショット後に必要なら gateway install --force | 偽切断を減らす | force 誤用で漂移が隠れる |
| pairing ループ | onboard、単一承認、古いブラウザ状態削除 | 身分チェーン回復 | 乱承認は監査穴 |
| HTTPS のみ失敗 | 証明書、HSTS、WS、allowedOrigins | エッジ起因を切り分け | ヘッダ誤りで 502 |
| doctor が境界を指摘 | workspaceAccess 調整とコールド再起動 | 偽再接続減 | 緩めすぎは負債 |
| ノート gateway 不安定 | 24x7 リモート Mac へ | 変動減 | 予算 |
管理 RPC の新しいホスト名やトンネル露出は CI OIDC とデプロイ鍵 と同じ票でレビューする。
実作手順：環境に合わせて置換する骨格コマンド
# 1) 両 semver の証拠
# openclaw --version
# openclaw gateway --version # サブコマンド名は配布版ドキュメントに従う
# 2) 公式段階（名称は CLI 版に合わせる）
# openclaw status
# openclaw gateway status
# openclaw logs --help
# openclaw doctor
# 3) ポリシー変更後は監督デーモンをコールド再起動
# launchctl / systemctl --user … は常駐記事参照
# 4) 逆プロキシ：curl -I と WebSocket クライアントで昇格ヘッダ確認
出力は秘匿情報を伏せてチケット化し、gateway install と linger の RPC 検証節と突き合わせる。
推奨読書順
本文のあと gateway 常駐 → 4.x doctor → 逆プロキシ TLS → 最小権限 → トップ の順を推奨。
FAQ と SFTPMAC ホスト型リモート Mac
すぐアンインストールすべき？
いいえ。版とエッジ検証を先に完了し、整合性が証明不能な場合のみアンインストール境界を検討する。
ペアリングと新セキュリティ基準が衝突する
承認フローを文書化し workspaceAccess 変更と同じ変更管理に載せる。
コミュニティのダウングレード手順は？
一時的な橋渡しに留め、semver と巻き戻し窓を必ず記録する。
まとめ：切断とペアリング要求は複合信号。semver を二重に記録し、公式段階を踏み、TLS／WebSocket を検証し、監督サービスをコールド再起動する。
限界：自己管理ノートは睡眠とブラウザ変動が残る。SFTPMAC のホスト型 リモート Mac はゲートウェイとワークスペースとファイル配信を同一運用面に置き、アップグレード証拠を揃えやすい。
版二点＋doctor 要約＋成功チャネル往復をリリースゲートに固定する。