移転した城門と十八枚の旧ビザ：launch_credentials_unavailable の全庫診断、発行者のみを信頼する鍵、そして零遮断の再検証

古い都の城門はすでに移ろうとしていたのに、旅人の懐にはまだ旧い門印を押された通行証が眠っていた——この日の診断は、「復元失敗」という一枚のダイアログから始まった。

一、ダイアログとそのエラーコード

午後二時十七分、Hermes デスクトップは赤い文字を掲げた。復元失敗、launch_credentials_unavailable。十月以前に生まれたセッションを開けば、ダイアログは約束したように現れる。ログの中でゲートウェイは同じ復元要求を四度拒み、その文面は公文のように静かだった。session.resume refused for profile=default: launch_credentials_unavailable field=provider detail=custom:custom no longer serves the saved endpoint; select a model to continue——保存されたエンドポイントはすでに名乗りを上げていない、モデルを選び直せ、という訳である。

二、これは故障ではない、警備の勝利だ

ログからソースへ掘り進めば、事件は一気に明けた。旧セッションの行には http://127.0.0.1:3000/v1 が釘付けにされていた——ローカル Docker 時代の new-api 港である。遷都の後、new-api は丸ごと 192.168.5.21:3000 へ移り、config もとっくに新港を指していた。ただ旧いセッションの行だけが、死んだ住所に釘付けのままだった。そして Hermes のルート境界設計は、自らのソースの注釈に家訓のように刻まれている。一つの鍵は、それを発行したエンドポイントにのみ有効であり、それを他所へ送ることは漏洩にほかならない。ゆえにゲートウェイは門神を演じる道を選び、もはや誰も名乗らない城門へ資格情報を手渡さなかった。デスクトップが見せたのは launch_credentials_unavailable の一言——ダイアログは警備体制の水面上の氷山の一角にすぎない。

三、精査、再結合、再検証

診断は三段の行軍で進み、一歩ごとに足跡を残した。

• 精査：固定ルートを持つセッション 41 本を一つずつふるいにかけ、18 本が死んだ住所に釘付けと判明——16 本が 127.0.0.1:3000、2 本は八月にすでに除名された tokenrhythm.studio（config にその provider はなく、.env に鍵もない）。歴史上のルートは十一種、147 本のセッションがそれぞれ出生の港を記憶している。
• 再結合：変えたのは saved base_url のみ（gateway_runtime の使用量印もともに運んだ）。モデルも provider も対話履歴も一バイトも動かさない。原値は先に二つの JSON バックアップとして残され（16 行、8769 バイト）、退却の鍵もいっしょに庫入りした。
• 再検証：ゲートウェイ自身の same_route と _endpoint_owner で一つずつ関所を通す——41 本を検査、34 本が profile の現ルートへ還り、なお遮断されているもの、零。

仕上げに、この一事例を hermes-agent 技能庫の troubleshooting.md に書き加えた。次にこの門を叩く人が、回り道を一つ減らせるように。

四、門の所在は変わっても、掟は変わらない

遷都は地理の出来事であり、ルートは契約の出来事である。城門は移っても、鍵を発行する論理は曇ってはならない。ポートは変わっても、資格情報の帰属はぼやけてはならない。今回の出来事の本質はむしろここにある。壊れたものは何もなく、システムは主人の見えない誓いを忠実に守っていたという事実である。主人の目には「復元失敗」としか映らなかったその弾幕を、ログは「発行を拒む」と記していた。同一の挙動、二つの物語。診断の価値は何を直したかではなく、次の確認にある。止めるべきものは、一度も通していない。